[Tinyos-alliance] Bridge info for the next 6 weeks

[Nachman, Lama]

Hi all,

I reserved the bridge for the next 6 weeks, here is the info below.

 

Thanks,

 

Lama

 

Date 

Bridge Info Summary 

Tuesday, February 7, 2006 11:00 AM US Pacific Time 

Where: 8-356-2663, 916-356-2663, Bridge: 4, Passcode: 5529301 

Tuesday, February 14, 2006 11:00 AM US Pacific Time 

Where: 8-356-2663, 916-356-2663, Bridge: 1, Passcode: 6811728 

Tuesday, February 21, 2006 11:00 AM US Pacific Time 

Where: 8-356-2663, 916-356-2663, Bridge: 2, Passcode: 1169809 

Tuesday, February 28, 2006 11:00 AM US Pacific Time 

Where: 8-356-2663, 916-356-2663, Bridge: 3, Passcode: 3951185 

Tuesday, March 7, 2006 11:00 AM US Pacific Time 

Where: 8-356-2663, 916-356-2663, Bridge: 4, Passcode: 0695768 

Tuesday, March 14, 2006 11:00 AM US Pacific Time 

Where: 8-356-2663, 916-356-2663, Bridge: 1, Passcode: 5708390 

 

 

-----Original Message-----
From: tinyos-alliance-bounces at millennium.berkeley.edu
[mailto:tinyos-alliance-bounces at millennium.berkeley.edu] On Behalf Of
David E. Culler
Sent: Tuesday, January 31, 2006 1:38 PM
To: tinyos-alliance at millennium.berkeley.edu
Subject: [Tinyos-alliance] Notes from IP / Source telecon

 

Participants:

 

David Culler

Adam Wolisz

Lama

Phillipe

Matt

Kristin

Ramesh

 

Background

IP

- IETF style: provide notification, mechanism to contribute, 

organization decides if it wants to steer clear

- WWW / Zigbee: provide IP pool. When you join to share with others 

inside, but not outside.

 

Licensing models

 

BSD - do what you want, except remove copyright or sue

Apache - BSD with accreditation

MPL - you must return changes, but you can build around it without 

obligation

LGPL - dynamic linking to GPL code OK

GPL - give back whatever you do

Dual-License - buy out of opensource obligations (typically with GPL)

 

Discussion

-----------------------------------------------------

 

Culler - layout basic alternatives above

 

Ramesh - IETF processes

- WGs tend steer clear of proprietary IP

- not allow people that are based on standards that are based on 

proprietary standards

 

Matt - clarify IP vs source license

 

Lama - Intel tends to have trouble with Zigbee

even declaring all the IP that's relevant is problematic

 

David

Producing a full list of potentially relevant IP is problematic for 

universities too.

 

Kristin

what is the motivation for including a pool? Besides promotion of the 

value of the organization itself?

 

David

Companies working together want to ensure that others won't block them. 

All give and all get something back.

 

Philippe

good to obtain some of the benefits seen in IETF

mistake to not mention it at all

 

Ramesh

RFC3979 - IETF wg prefer open

discretion to adopt tech with FAND

 

General consensus on IETF

 

-----------------------------------------------------

Source License terms

 

David - outline of relevant models

 

Rob - Most sources carry something closer to academic license

- does not include advertising clause

- copyright retention in binary distribution

 

Adam

- what is the problem with Apache license?

 

Rob

- gives contributor a little more visibility

 

David

- pro: individual credit

- con: chain can get very large, apache you reference the organization 

not the individual

 

Adam

- can you reference an old chain

 

Philippe

- simpler if there was only one type of license

- keep it close to what it is now

 

Matt

- if all act in good faith, would not be an issue

 

Rob

- past issues: change in license did not have any consultation

- TOS2 wouldn't want to have just one to reference

 

Matt

- what if all had same position

 

Rob

- could rely on nesc doc

 

Lama

- apache: individual vs group attribution

 

Ramesh

- third option would be individual working groups

 

Adam

- individual attribution is a motivation

 

Philippe

- important for students to get recognition within alliance

- may not matter on the outside

 

Rob

- disagree, audience to much bigger community

- might motivate people outside the alliance

 

Matt

- who would actually hold the copyright? The alliance or the contributor

 

Adam

- two issues can be separate

 

David

- issue is what is the set that we are willing to accept

 

Lama

- is documentation in the source code sufficient

- does it have to be in all other documents

 

Rob

- it would need to be in the manuals

 

General interest in allowing something like apache

Need to find mechanisms that make it effective.

 

 

Lama

- what about checking in object code

 

 

Matt

- should we push for a single homgenous license

- eventhough it might be impossible

 

Philippe

- what about individual working groups

- might find agreement there

 

Adam

- too much heterogeneity is a problem

 

Rob

- alliance compliant license

- in favor giving copyright to the alliance with individual attribution

 

David

- is it naive to expect all these organization to agree to common

 

General consensus on expanding the options and providing attribution, 

attempting consolidation

 

 

next => consoldate and talk voting / committee process

 

 

 

 

 

 

 

 

 

 

_______________________________________________

Tinyos-alliance mailing list

Tinyos-alliance at millennium.berkeley.edu

https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-all
iance

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-alliance/attachments/20060206/dd3a44e7/attachment-0001.html