Council Meeting
Re: Council Meeting
Re: Council Meeting
2012-04-18 17:30 UTC
On Wed, Apr 18, 2012 at 1:17 PM, Quim Gil <quim.gil@nokia.com> wrote:
> On 04/17/2012 01:31 PM, Quim Gil wrote:
>
>> I sent a first question to the Nokia legal team and I got a first
>> answer. They need to know the exact list of packages, with a special
>> attention of any proprietary binary coming from third parties.
>>
>
> Forgot to say that I asked already Soumya Bijjal and Niels about those
> lists.
>
> A starting point:
>
> Harmattan:
> http://harmattan-dev.nokia.**com/stable/harmattan/beta3_vs_**
> final_content_comparison.html<http://harmattan-dev.nokia.com/stable/harmattan/beta3_vs_final_content_comparison.html>
>
> Fremantle:
> http://repository.maemo.org/**stable/fremantle/maemo5.0_**
> update6_vs_maemo5.0_update7_**content_comparison.html<http://repository.maemo.org/stable/fremantle/maemo5.0_update6_vs_maemo5.0_update7_content_comparison.html>
>
> Diablo:
> http://repository.maemo.org/**stable/diablo/4.1.1_vs_4.1.2_**
> content_comparison.html<http://repository.maemo.org/stable/diablo/4.1.1_vs_4.1.2_content_comparison.html>
>
> Chinook:
> http://repository.maemo.org/**stable/chinook/4.0_vs_4.0.1_**
> content_comparison.html<http://repository.maemo.org/stable/chinook/4.0_vs_4.0.1_content_comparison.html>
>
> I have asked them whether all those packages are REQUIRED for an OBS
> target.
>
> The open source package are irrelevant since they can be "re-hosted" and
> redistributed already now.
>
> Then we have the proprietary packages. All they appear as 'Nokia binaries'
> but in fact some of those my have a non-Nokia copyright. This is what
> Soumya will need to parse i order to find the 3rd party proprietary
> binaries.
>
> From a legal point of view Nokia and non-Nokia binaries are two totally
> different categories since Nokia cannot grant any permissions for the
> latter on its own.
>
> If there are 3rd party binaries that are required to build OBS targets
> then I will go back to my point of how worth it is to change the current
> situation given that there is no actual risk anybody could point to on
> Nokia pulling hosting & funds for the servers where that software is
> currently hosted. As explained in the IRC meeting, changing the terms for
> the Nokia binaries without a strong business reason is already complex. I
> expect convincing legal teams in other companies under the same arguments
> to be even more complicated.
>
>
>
Thanks for the lists. Sure, if it turns out there are 3rd party binaries
needed for an OBS target, then let's pause the process and discuss the
situation.
Rob
> On 04/17/2012 01:31 PM, Quim Gil wrote:
>
>> I sent a first question to the Nokia legal team and I got a first
>> answer. They need to know the exact list of packages, with a special
>> attention of any proprietary binary coming from third parties.
>>
>
> Forgot to say that I asked already Soumya Bijjal and Niels about those
> lists.
>
> A starting point:
>
> Harmattan:
> http://harmattan-dev.nokia.**com/stable/harmattan/beta3_vs_**
> final_content_comparison.html<http://harmattan-dev.nokia.com/stable/harmattan/beta3_vs_final_content_comparison.html>
>
> Fremantle:
> http://repository.maemo.org/**stable/fremantle/maemo5.0_**
> update6_vs_maemo5.0_update7_**content_comparison.html<http://repository.maemo.org/stable/fremantle/maemo5.0_update6_vs_maemo5.0_update7_content_comparison.html>
>
> Diablo:
> http://repository.maemo.org/**stable/diablo/4.1.1_vs_4.1.2_**
> content_comparison.html<http://repository.maemo.org/stable/diablo/4.1.1_vs_4.1.2_content_comparison.html>
>
> Chinook:
> http://repository.maemo.org/**stable/chinook/4.0_vs_4.0.1_**
> content_comparison.html<http://repository.maemo.org/stable/chinook/4.0_vs_4.0.1_content_comparison.html>
>
> I have asked them whether all those packages are REQUIRED for an OBS
> target.
>
> The open source package are irrelevant since they can be "re-hosted" and
> redistributed already now.
>
> Then we have the proprietary packages. All they appear as 'Nokia binaries'
> but in fact some of those my have a non-Nokia copyright. This is what
> Soumya will need to parse i order to find the 3rd party proprietary
> binaries.
>
> From a legal point of view Nokia and non-Nokia binaries are two totally
> different categories since Nokia cannot grant any permissions for the
> latter on its own.
>
> If there are 3rd party binaries that are required to build OBS targets
> then I will go back to my point of how worth it is to change the current
> situation given that there is no actual risk anybody could point to on
> Nokia pulling hosting & funds for the servers where that software is
> currently hosted. As explained in the IRC meeting, changing the terms for
> the Nokia binaries without a strong business reason is already complex. I
> expect convincing legal teams in other companies under the same arguments
> to be even more complicated.
>
>
>
Thanks for the lists. Sure, if it turns out there are 3rd party binaries
needed for an OBS target, then let's pause the process and discuss the
situation.
Rob
Re: Council Meeting
Craig Woodward
=============
On Wed, Apr 18, 2012 at 1:17 PM, Quim Gil <quim.gil@nokia.com> wrote:
> On 04/17/2012 01:31 PM, Quim Gil wrote:
>
> From a legal point of view Nokia and non-Nokia binaries are two totally
> different categories since Nokia cannot grant any permissions for the
> latter on its own.
> [...]
> I expect convincing legal teams in other companies under the same arguments
> to be even more complicated.
---- robert bauer <nybauer@gmail.com> wrote:
>Thanks for the lists. Sure, if it turns out there are 3rd party binaries
>needed for an OBS target, then let's pause the process and discuss the
>situation.
I agree if 3rd party binaries are involved we should pause to examine the possible impact.
One thing I want to keep in mind though, is that Nokia already has _some_ kind of agreement in place to redistribute these 3rd party binaries to end users as part of the existing SDK. Those agreements _may_ in fact already allow for what's being asked, which could mean no further input or discussions would be required with that/those 3rd parties.
Having worked in the field, I can tell you that it's likely that Nokia lawyers took the _most_ restrictive component policy (which may in fact have been for a Nokia component) and blanket applied that to _everything_ for simplicity sake. If the components that triggered the hosting policy are not in the sub-set needed for OBS, we may be able to ask for that sub-set to be specifically called out with a slightly less strict policy. So even if there are 3rd party bits, it may not require additional input from them if the existing contracts, for that sub-set, are open enough.
In a nutshell: The mere existence of a single 3rd party element shouldn't automatically trigger a derailment the idea.
We definitely need to determine exactly what's needed though, and identify if (or how many) 3rd parties are involved. I suspect it will be at most two or three, which could still merit a request of a quick re-examine of the existing terms to see if this is doable without changing anything with the 3rd parties. That feedback may also inform us of what structure could be used to do this without changing those terms (eg. would forming a legal entity to host them even be a legally viable alternative.)
Also, let's not forget this tech is aging. Some components may have already been opened up more by the vendors themselves. Some vendors may be willing to open part of their older tech in ways they wouldn't have several years ago.
-Woody(14619)
On Wed, Apr 18, 2012 at 1:17 PM, Quim Gil <quim.gil@nokia.com> wrote:
> On 04/17/2012 01:31 PM, Quim Gil wrote:
>
> From a legal point of view Nokia and non-Nokia binaries are two totally
> different categories since Nokia cannot grant any permissions for the
> latter on its own.
> [...]
> I expect convincing legal teams in other companies under the same arguments
> to be even more complicated.
---- robert bauer <nybauer@gmail.com> wrote:
>Thanks for the lists. Sure, if it turns out there are 3rd party binaries
>needed for an OBS target, then let's pause the process and discuss the
>situation.
I agree if 3rd party binaries are involved we should pause to examine the possible impact.
One thing I want to keep in mind though, is that Nokia already has _some_ kind of agreement in place to redistribute these 3rd party binaries to end users as part of the existing SDK. Those agreements _may_ in fact already allow for what's being asked, which could mean no further input or discussions would be required with that/those 3rd parties.
Having worked in the field, I can tell you that it's likely that Nokia lawyers took the _most_ restrictive component policy (which may in fact have been for a Nokia component) and blanket applied that to _everything_ for simplicity sake. If the components that triggered the hosting policy are not in the sub-set needed for OBS, we may be able to ask for that sub-set to be specifically called out with a slightly less strict policy. So even if there are 3rd party bits, it may not require additional input from them if the existing contracts, for that sub-set, are open enough.
In a nutshell: The mere existence of a single 3rd party element shouldn't automatically trigger a derailment the idea.
We definitely need to determine exactly what's needed though, and identify if (or how many) 3rd parties are involved. I suspect it will be at most two or three, which could still merit a request of a quick re-examine of the existing terms to see if this is doable without changing anything with the 3rd parties. That feedback may also inform us of what structure could be used to do this without changing those terms (eg. would forming a legal entity to host them even be a legally viable alternative.)
Also, let's not forget this tech is aging. Some components may have already been opened up more by the vendors themselves. Some vendors may be willing to open part of their older tech in ways they wouldn't have several years ago.
-Woody(14619)
Re: Council Meeting
2012-04-18 19:34 UTC
On 04/18/2012 12:08 PM, ext Craig Woodward wrote:
> Also, let's not forget this tech is aging. Some components may have
> already been opened up more by the vendors themselves. Some vendors
> may be willing to open part of their older tech in ways they wouldn't
> have several years ago.
I'm not holding my breath. Third party components might have been
developed by subcontractors under certain premises, making things even
more complicated. Aging tech also means older contracts handled by
people not around, making it very easy to get gray answers defaulting to
silence or nope-sorry in a situation like this.
--
Quim
> Also, let's not forget this tech is aging. Some components may have
> already been opened up more by the vendors themselves. Some vendors
> may be willing to open part of their older tech in ways they wouldn't
> have several years ago.
I'm not holding my breath. Third party components might have been
developed by subcontractors under certain premises, making things even
more complicated. Aging tech also means older contracts handled by
people not around, making it very easy to get gray answers defaulting to
silence or nope-sorry in a situation like this.
--
Quim
Re: Council Meeting
2012-04-19 09:43 UTC
On 11 April 2012 15:01, robert bauer <nybauer@gmail.com> wrote:
> There will be a Council meeting (IRC - #maemo-meeting) at 15:00 UTC on
> Tuesday April 17. Preliminary agenda is as follows:
>
> Preliminary Agenda:
> 1. Welcome (back) to QGil/Update from Nokia(?)
> 2. Community OBS
> 3. Council Election voting
> 4. Left-over topics from last council meeting (if timely)
> A. Qt style license agreement for maemo
> B. Co-maintainership for CSSU repo
Will minutes, and a link to the full log, be circulated (preferably
published on the Council blog) for those who couldn't attend but want
to see the outcome?
Thanks in advance,
Andrew
--
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org/
> There will be a Council meeting (IRC - #maemo-meeting) at 15:00 UTC on
> Tuesday April 17. Preliminary agenda is as follows:
>
> Preliminary Agenda:
> 1. Welcome (back) to QGil/Update from Nokia(?)
> 2. Community OBS
> 3. Council Election voting
> 4. Left-over topics from last council meeting (if timely)
> A. Qt style license agreement for maemo
> B. Co-maintainership for CSSU repo
Will minutes, and a link to the full log, be circulated (preferably
published on the Council blog) for those who couldn't attend but want
to see the outcome?
Thanks in advance,
Andrew
--
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org/
Re: Council Meeting
2012-04-19 10:13 UTC
Hi
19. huhtikuuta 2012 12.43 Andrew Flegg <andrew@bleb.org> kirjoitti:
> On 11 April 2012 15:01, robert bauer <nybauer@gmail.com> wrote:
> > There will be a Council meeting (IRC - #maemo-meeting) at 15:00 UTC on
> > Tuesday April 17. Preliminary agenda is as follows:
> >
> > Preliminary Agenda:
> > 1. Welcome (back) to QGil/Update from Nokia(?)
> > 2. Community OBS
> > 3. Council Election voting
> > 4. Left-over topics from last council meeting (if timely)
> > A. Qt style license agreement for maemo
> > B. Co-maintainership for CSSU repo
>
> Will minutes, and a link to the full log, be circulated (preferably
> published on the Council blog) for those who couldn't attend but want
> to see the outcome?
>
>
yes. please. I missed the meeting and been waiting for the logs and minutes
to be published.
-Timo
>
> --
> Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org/
>
19. huhtikuuta 2012 12.43 Andrew Flegg <andrew@bleb.org> kirjoitti:
> On 11 April 2012 15:01, robert bauer <nybauer@gmail.com> wrote:
> > There will be a Council meeting (IRC - #maemo-meeting) at 15:00 UTC on
> > Tuesday April 17. Preliminary agenda is as follows:
> >
> > Preliminary Agenda:
> > 1. Welcome (back) to QGil/Update from Nokia(?)
> > 2. Community OBS
> > 3. Council Election voting
> > 4. Left-over topics from last council meeting (if timely)
> > A. Qt style license agreement for maemo
> > B. Co-maintainership for CSSU repo
>
> Will minutes, and a link to the full log, be circulated (preferably
> published on the Council blog) for those who couldn't attend but want
> to see the outcome?
>
>
yes. please. I missed the meeting and been waiting for the logs and minutes
to be published.
-Timo
>
> --
> Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org/
>
Re: Council Meeting
2012-04-19 10:48 UTC
On Sun, Apr 15, 2012 at 03:21:38PM +0100, Andrew Flegg wrote:
> 3) Get a permanent licence grant for maemo.org to ship Nokia binaries
> (e.g. flasher, firmware) and use them in the build process (SDKs in
> autobuilder and COBS).
I think these two issues should be kept separate.
A redistribution licence for closed binaries is something extremely
unlikely to happen, time to accept that and move on.
On the other hand, use of nokia-binaries in builders should be already
covered by the existing licence[1]. The only problem areas that I can
see (IANAL etc disclaimers apply) are:
A. backups (only one copy permitted),
B. no legal entity to become the "Licensee",
C. agreements between licensee and "employees" (build service admins etc)
A is an annoyance, but we could probably jump through some hoops and
live with it as the bits in question are pretty much static. A possible
answer to B & C might be:
> 1) Create a self-governing, non-profit legal entity for maemo.org. It is
> unclear (to me), what this would accomplish.
Other options would be along the lines of another party such as Mer or
Nemein being the licensee and managing access.
L.
[1] Fremantle version: <http://tablets-dev.nokia.com/eula/index.php>.
The Diablo version in my scratchbox instance lacks clause 3.2 but is
otherwise identical.
> 3) Get a permanent licence grant for maemo.org to ship Nokia binaries
> (e.g. flasher, firmware) and use them in the build process (SDKs in
> autobuilder and COBS).
I think these two issues should be kept separate.
A redistribution licence for closed binaries is something extremely
unlikely to happen, time to accept that and move on.
On the other hand, use of nokia-binaries in builders should be already
covered by the existing licence[1]. The only problem areas that I can
see (IANAL etc disclaimers apply) are:
A. backups (only one copy permitted),
B. no legal entity to become the "Licensee",
C. agreements between licensee and "employees" (build service admins etc)
A is an annoyance, but we could probably jump through some hoops and
live with it as the bits in question are pretty much static. A possible
answer to B & C might be:
> 1) Create a self-governing, non-profit legal entity for maemo.org. It is
> unclear (to me), what this would accomplish.
Other options would be along the lines of another party such as Mer or
Nemein being the licensee and managing access.
L.
[1] Fremantle version: <http://tablets-dev.nokia.com/eula/index.php>.
The Diablo version in my scratchbox instance lacks clause 3.2 but is
otherwise identical.
Re: Council Meeting
2012-04-19 15:34 UTC
On Tue, Apr 17, 2012 at 01:31:30PM -0700, Quim Gil wrote:
> I sent a first question to the Nokia legal team and I got a first
> answer. They need to know the exact list of packages, with a special
> attention of any proprietary binary coming from third parties.
Here is a list of all 'nokia-binaries' packages that are build
dependencies of packages in Diablo[1] extras-devel/free:
libgpsbt
libgpsbt-dev
libgpsmgr
libgpsmgr-dev
liblocation-dev
libosso-abook-dev
libosso-rtcom-accounts-dev
osso-help-ui
osso-mission-control
That's just 9 packages out of a total of 72 (and a few of these look
like run-time dependencies accidentally also entered as build-time
ones).
8 of these declare (C) Nokia in their debian/copyright files. The only
exception is liblocation-dev which lacks any copyright/licence
information. This just looks like bad packaging, and the actual header
files all state (C) Nokia Corporation, but someone should check that
anyway.
However the real question for the legal team is whether anything more
than the current EULA is required for a /build service/, ie a situation
where the binaries are only present on a system in order to build packages
for Maemo devices (the "Purpose") and no redistribution is required or
intended.
L.
[1] I don't have the necessary marbles here to extract equivalent
Fremantle or Harmattan lists, but it should be just a matter of
extracting build dependencies out of the source repo's Sources file,
getting a list of packages in the nokia-binaries repository, sorting
both and running "comm -12" on them.
> I sent a first question to the Nokia legal team and I got a first
> answer. They need to know the exact list of packages, with a special
> attention of any proprietary binary coming from third parties.
Here is a list of all 'nokia-binaries' packages that are build
dependencies of packages in Diablo[1] extras-devel/free:
libgpsbt
libgpsbt-dev
libgpsmgr
libgpsmgr-dev
liblocation-dev
libosso-abook-dev
libosso-rtcom-accounts-dev
osso-help-ui
osso-mission-control
That's just 9 packages out of a total of 72 (and a few of these look
like run-time dependencies accidentally also entered as build-time
ones).
8 of these declare (C) Nokia in their debian/copyright files. The only
exception is liblocation-dev which lacks any copyright/licence
information. This just looks like bad packaging, and the actual header
files all state (C) Nokia Corporation, but someone should check that
anyway.
However the real question for the legal team is whether anything more
than the current EULA is required for a /build service/, ie a situation
where the binaries are only present on a system in order to build packages
for Maemo devices (the "Purpose") and no redistribution is required or
intended.
L.
[1] I don't have the necessary marbles here to extract equivalent
Fremantle or Harmattan lists, but it should be just a matter of
extracting build dependencies out of the source repo's Sources file,
getting a list of packages in the nokia-binaries repository, sorting
both and running "comm -12" on them.
Re: Council Meeting
2012-04-19 18:43 UTC
On śro 18 kwi 2012 21:34:06 CEST, Quim Gil <quim.gil@nokia.com> wrote:
>
> I'm not holding my breath. Third party components might have been
> developed by subcontractors under certain premises, making things even
> more complicated. Aging tech also means older contracts handled by
> people not around, making it very easy to get gray answers defaulting to
> silence or nope-sorry in a situation like this.
>
> --
> Quim
>
>
>
And what about more important part of woody's mail, about possibility of using current license (that made components in question into SDK on the first place)? Is there man power in Nokia "law" team to determine that?
/Estel
>
> I'm not holding my breath. Third party components might have been
> developed by subcontractors under certain premises, making things even
> more complicated. Aging tech also means older contracts handled by
> people not around, making it very easy to get gray answers defaulting to
> silence or nope-sorry in a situation like this.
>
> --
> Quim
>
>
>
And what about more important part of woody's mail, about possibility of using current license (that made components in question into SDK on the first place)? Is there man power in Nokia "law" team to determine that?
/Estel
Re: Council Meeting
2012-04-20 02:19 UTC
On Thu, Apr 19, 2012 at 6:48 AM, Lucas Maneos <maemo@subs.maneos.org> wrote:
> On Sun, Apr 15, 2012 at 03:21:38PM +0100, Andrew Flegg wrote:
> > 3) Get a permanent licence grant for maemo.org to ship Nokia binaries
> > (e.g. flasher, firmware) and use them in the build process (SDKs in
> > autobuilder and COBS).
>
>
>
> Other options would be along the lines of another party such as Mer or
> Nemein being the licensee and managing access.
>
> L.
>
>
Actually, this proposal started with Mer. They saw MeeGo OBS was going
away and asked if maemo was interested in it. They are resource
constrained so it looks as if maemo will bring some desired resources as
its contribution to the cOBS. The working premise AIUI is that the cOBS
will be in a separate legal entity from Mer project but the usual suspects
will be maintaining it.
Rob
> On Sun, Apr 15, 2012 at 03:21:38PM +0100, Andrew Flegg wrote:
> > 3) Get a permanent licence grant for maemo.org to ship Nokia binaries
> > (e.g. flasher, firmware) and use them in the build process (SDKs in
> > autobuilder and COBS).
>
>
>
> Other options would be along the lines of another party such as Mer or
> Nemein being the licensee and managing access.
>
> L.
>
>
Actually, this proposal started with Mer. They saw MeeGo OBS was going
away and asked if maemo was interested in it. They are resource
constrained so it looks as if maemo will bring some desired resources as
its contribution to the cOBS. The working premise AIUI is that the cOBS
will be in a separate legal entity from Mer project but the usual suspects
will be maintaining it.
Rob
> I sent a first question to the Nokia legal team and I got a first
> answer. They need to know the exact list of packages, with a special
> attention of any proprietary binary coming from third parties.
Forgot to say that I asked already Soumya Bijjal and Niels about those
lists.
A starting point:
Harmattan:
http://harmattan-dev.nokia.com/stable/harmattan/beta3_vs_final_content_comparison.html
Fremantle:
http://repository.maemo.org/stable/fremantle/maemo5.0_update6_vs_maemo5.0_update7_content_comparison.html
Diablo:
http://repository.maemo.org/stable/diablo/4.1.1_vs_4.1.2_content_comparison.html
Chinook:
http://repository.maemo.org/stable/chinook/4.0_vs_4.0.1_content_comparison.html
I have asked them whether all those packages are REQUIRED for an OBS
target.
The open source package are irrelevant since they can be "re-hosted" and
redistributed already now.
Then we have the proprietary packages. All they appear as 'Nokia
binaries' but in fact some of those my have a non-Nokia copyright. This
is what Soumya will need to parse i order to find the 3rd party
proprietary binaries.
From a legal point of view Nokia and non-Nokia binaries are two totally
different categories since Nokia cannot grant any permissions for the
latter on its own.
If there are 3rd party binaries that are required to build OBS targets
then I will go back to my point of how worth it is to change the current
situation given that there is no actual risk anybody could point to on
Nokia pulling hosting & funds for the servers where that software is
currently hosted. As explained in the IRC meeting, changing the terms
for the Nokia binaries without a strong business reason is already
complex. I expect convincing legal teams in other companies under the
same arguments to be even more complicated.
--
Quim