[Tinyos-alliance] Notes from IP / Source telecon

[Kristin Wright]

I'll volunteer to take notes next week. Maybe we can take turns with the notes.
-kw

On 1/31/06, David E. Culler <culler at eecs.berkeley.edu> wrote:
> 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-alliance
>