Home » General (non-technical) » Eclipse Foundation » IP Evaluation for Libraries: Processes and tools needed?
| IP Evaluation for Libraries: Processes and tools needed? [message #16761] |
Wed, 09 March 2005 04:54  |
Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Greetings all,
I am the project lead for the Eclipse Communications Framework
technollgy project. We have occasion to want to use several open
source libraries to help us implement some open protocols that we wish
to support (e.g. SIP--session initiation protocol).
Of course part of using libraries that we did not develop is to be able
to quickly find and evaluate these libraries...and verify the following
kinds of things:
a) the license(s) that the library is distributed under are compatible
with the EPL
b) that the history (e.g. ownership and copyright structure) of all the
code and any attached resources (e.g. images/sounds, etc) is clear and
consistent
c) that the implementation is solid (of course)
d) that the source code is well structured
e) that the owners/original developers are in favor of redistribution
via an Eclipse Foundation project
f) that the source for the library is available either via the
foundation or via some other means (e.g. download via sourceforge, etc)
with terms that are compatible with EPL
My questions to you:
a) As foundation members, do you feel foundation committers generally
understand all the steps necessary to assure that a library can be used
with a given project while keeping all of Eclipse 'ip-clean'?
b) Are more/better tools desired to aid this process (e.g. some basic
filters to search through codebases for copyright notices, license
notices...for both EPL compatible and incompatible)? Other ideas?
c) Is there/could there be a table that includes all the 'popular' open
source licenses and their status WRT EPL compatibility? e.g. GPL - no,
MPL - yes, etc.
d) Would it be helpful to have a 'checklist' for technical people to use
to help them organize the questions for the library developers?
e) Would it be helpful to have a specific newsgroup or forum for
discussion/consideration of IP issues for library usage in foundation
projects?
e) What other things do people feel are needed to support the easy but
thorough IP evaluation of open source libraries?
Thanksinadvance,
Scott
|
|
|
| Re: IP Evaluation for Libraries: Processes and tools needed? [message #16764 is a reply to message #16761] |
Wed, 09 March 2005 16:33  |
 Jim Adams
Messages: 160
Registered: July 2009 |
Senior Member |
|
|
While I can not, myself speak for SAS, I do work for Rich Main who is one of
the add-in members on the board. I have some comments on this.
"Scott Lewis" <slewis@composent.com> wrote in message
news:d0lvht$28t$1@www.eclipse.org...
> Greetings all,
>
> I am the project lead for the Eclipse Communications Framework technollgy
> project. We have occasion to want to use several open source libraries
> to help us implement some open protocols that we wish to support (e.g.
> SIP--session initiation protocol).
>
> Of course part of using libraries that we did not develop is to be able to
> quickly find and evaluate these libraries...and verify the following kinds
> of things:
>
> a) the license(s) that the library is distributed under are compatible
> with the EPL
> b) that the history (e.g. ownership and copyright structure) of all the
> code and any attached resources (e.g. images/sounds, etc) is clear and
> consistent
> c) that the implementation is solid (of course)
> d) that the source code is well structured
> e) that the owners/original developers are in favor of redistribution via
> an Eclipse Foundation project
> f) that the source for the library is available either via the foundation
> or via some other means (e.g. download via sourceforge, etc) with terms
> that are compatible with EPL
>
> My questions to you:
>
> a) As foundation members, do you feel foundation committers generally
> understand all the steps necessary to assure that a library can be used
> with a given project while keeping all of Eclipse 'ip-clean'?
I feel that most folks don't understand this issue.
> b) Are more/better tools desired to aid this process (e.g. some basic
> filters to search through codebases for copyright notices, license
> notices...for both EPL compatible and incompatible)? Other ideas?
> c) Is there/could there be a table that includes all the 'popular' open
> source licenses and their status WRT EPL compatibility? e.g. GPL - no,
> MPL - yes, etc.
This would be an interesting and useful resource.
> d) Would it be helpful to have a 'checklist' for technical people to use
> to help them organize the questions for the library developers?
> e) Would it be helpful to have a specific newsgroup or forum for
> discussion/consideration of IP issues for library usage in foundation
> projects?
> e) What other things do people feel are needed to support the easy but
> thorough IP evaluation of open source libraries?
One problem that I see is more technical. How would these libraries be
generally made available? Would the thirdparty library be modified to make
is a plugin library jar or would it be wrapped with a plugin and left
unmodified? This question has bothered us in our own projects.
>
> Thanksinadvance,
>
> Scott
>
>
|
|
|
| Re: IP Evaluation for Libraries: Processes and tools needed? [message #16767 is a reply to message #16761] |
Wed, 09 March 2005 23:02 |
Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
I am not sure if (a) and (b) on your first list are the right questions. If
you are interested in using a third party package, the current steps are:
1) ask your PMC for review and approval. To be clear, the PMC's role is to
approve the package on its technical merits (generally, what you have listed
at (c) and (d) in your first list), not to provide the IP due diligence. If
you ask the EMO to approve the inclusion a third party package, the first
thing we will ask for is your PMC's concurrence. So you might as well start
there.
2) when it comes to license compatibility, one of the easiest things to do
is check for precedents. If its been approved before, odds are it will be
again. Check out the list in http://www.eclipse.org/legal/epl/notice.html.
3) if/when the PMC approves, fill out the Contribution Questionnaire at
http://www.eclipse.org/legal/ContributionQuestionnairePart1- v1.0.htm. But
*please* do not expect an instantaneous approval. The due diligence process
takes days, if not weeks. Expecting approval in 24 hours just gets everyone
frustrated. If you have any questions about when you need to fill out the
form, read the preamble. It's a good start. If you have any additional
questions, send an email to emo@eclipse.org or janet.campbell@eclipse.org.
Janet is our brand-new full-time Manager of IP. This is what she does for a
living, and she is here to act as a resource for the entire community.
4) don't try to spend a lot of time checking into the provenance of the code
yourself. Odds are that you will be duplicating effort. Janet's job is to do
this. She may need to work with you to get answers to some questions, but
that is not the same thing as requiring the committer to be responsible for
the task. This needs to be a collaborative process.
The next issue which is what you have listed as (e) and (f) in your first
list. At the highest level (and yes I know there are execptions), these two
must be true if the package is under an EPL-compatible open source license.
We at Eclipse don't expect that our users will ask our permission to use
Eclipse. That's explicit in the terms of the CPL and EPL. So if the package
is open source, these questions should not typically come up. The corollary
of this is that it is strictly verbotten to include a package in Eclipse
which is *not* open source. That would cause our users no end of grief. Not
to mention the Foundation :-)
I hope this helps.
"Scott Lewis" <slewis@composent.com> wrote in message
news:d0lvht$28t$1@www.eclipse.org...
> Greetings all,
>
> I am the project lead for the Eclipse Communications Framework technollgy
> project. We have occasion to want to use several open source libraries
> to help us implement some open protocols that we wish to support (e.g.
> SIP--session initiation protocol).
>
> Of course part of using libraries that we did not develop is to be able to
> quickly find and evaluate these libraries...and verify the following kinds
> of things:
>
> a) the license(s) that the library is distributed under are compatible
> with the EPL
> b) that the history (e.g. ownership and copyright structure) of all the
> code and any attached resources (e.g. images/sounds, etc) is clear and
> consistent
> c) that the implementation is solid (of course)
> d) that the source code is well structured
> e) that the owners/original developers are in favor of redistribution via
> an Eclipse Foundation project
> f) that the source for the library is available either via the foundation
> or via some other means (e.g. download via sourceforge, etc) with terms
> that are compatible with EPL
>
> My questions to you:
>
> a) As foundation members, do you feel foundation committers generally
> understand all the steps necessary to assure that a library can be used
> with a given project while keeping all of Eclipse 'ip-clean'?
> b) Are more/better tools desired to aid this process (e.g. some basic
> filters to search through codebases for copyright notices, license
> notices...for both EPL compatible and incompatible)? Other ideas?
> c) Is there/could there be a table that includes all the 'popular' open
> source licenses and their status WRT EPL compatibility? e.g. GPL - no,
> MPL - yes, etc.
> d) Would it be helpful to have a 'checklist' for technical people to use
> to help them organize the questions for the library developers?
> e) Would it be helpful to have a specific newsgroup or forum for
> discussion/consideration of IP issues for library usage in foundation
> projects?
> e) What other things do people feel are needed to support the easy but
> thorough IP evaluation of open source libraries?
>
> Thanksinadvance,
>
> Scott
>
>
|
|
|
| Re: IP Evaluation for Libraries: Processes and tools needed? [message #16770 is a reply to message #16767] |
Thu, 10 March 2005 03:29 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Hi Mike,
Mike Milinkovich wrote:
> I am not sure if (a) and (b) on your first list are the right questions. If
> you are interested in using a third party package, the current steps are:
>
> 1) ask your PMC for review and approval. To be clear, the PMC's role is to
> approve the package on its technical merits (generally, what you have listed
> at (c) and (d) in your first list), not to provide the IP due diligence. If
> you ask the EMO to approve the inclusion a third party package, the first
> thing we will ask for is your PMC's concurrence. So you might as well start
> there.
I understand that this is the place to start for technical review. It
is where we started (with our previous efforts for ECF), but
unfortunately it doesn't have anything really to do with verifying the
IP status pf library code (although it is relevant to c & d on my list
below...I probably shouldn't have included c&d on this list, but too late).
>
> 2) when it comes to license compatibility, one of the easiest things to do
> is check for precedents. If its been approved before, odds are it will be
> again. Check out the list in http://www.eclipse.org/legal/epl/notice.html.
Sure...this is what we did as well. But if precedence doesn't exist
(most common case still) it doesn't necessarily make sense to exclude
from consideration...so wouldn't a license compatibility matrix help?
>
> 3) if/when the PMC approves, fill out the Contribution Questionnaire at
> http://www.eclipse.org/legal/ContributionQuestionnairePart1- v1.0.htm. But
> *please* do not expect an instantaneous approval. The due diligence process
> takes days, if not weeks. Expecting approval in 24 hours just gets everyone
> frustrated. If you have any questions about when you need to fill out the
> form, read the preamble. It's a good start. If you have any additional
> questions, send an email to emo@eclipse.org or janet.campbell@eclipse.org.
> Janet is our brand-new full-time Manager of IP. This is what she does for a
> living, and she is here to act as a resource for the entire community.
Right...I didn't mean to leave this out...obviously it's critical. I
was just trying to identify what the project teams could do in support
of Janet's/foundations work here...in order to avoid having the strategy
be to just submit everything that could be considered to the
contribution questionnaire...and thereby creating additional overload
for Janet/foundation.
>
> 4) don't try to spend a lot of time checking into the provenance of the code
> yourself. Odds are that you will be duplicating effort. Janet's job is to do
> this. She may need to work with you to get answers to some questions, but
> that is not the same thing as requiring the committer to be responsible for
> the task. This needs to be a collaborative process.
Maybe some additional input/tools to aid in the project team's 'due
dilligence' prior to getting Janet involved will help? Clearly we don't
want to duplicate effort...but if (e.g.) checking the code for
incompatible licenses could be automated to 80% with some simple
filtering tools that the project team could run then perhaps it would
save effort on everyone's part? This is the kind of thing I was
thinking about, but there may be other tools that would be more effective.
>
> The next issue which is what you have listed as (e) and (f) in your first
> list. At the highest level (and yes I know there are execptions), these two
> must be true if the package is under an EPL-compatible open source license.
> We at Eclipse don't expect that our users will ask our permission to use
> Eclipse. That's explicit in the terms of the CPL and EPL. So if the package
> is open source, these questions should not typically come up. The corollary
> of this is that it is strictly verbotten to include a package in Eclipse
> which is *not* open source. That would cause our users no end of grief. Not
> to mention the Foundation :-)
So should the project teams be expected to approach the authors of the
library with the question: will you object (legally or not) to having
this library redistributed via the foundation? Is this a reasonable
part of the project team's due dilligence for a library unders
consideration? Or should this be left to Janet/foundation?
I speak for myself, but I do feel that the project teams would be
willing to do more under the rubric of 'due dilligence' prior to
submitting the questionnaire...if it's clear *what that due dilligence
should consist of*, and that due dilligence can be aided with technology
(for the lazy among us), consultation with people who've been through
such a process before, some interaction with Janet, etc. So I guess
some clarification of what the project team's due diligence should
optimally consist of, along with some resources to support that due
dilligence (e.g. tools, communication aids, etc) would be desireable
from my point of view.
It seems that Jim Adam's responses to my initial list indicated some of
the clarification, tools, communication aids might be welcome for some
others...no? Does this seem reasonable?
Scott
>
> I hope this helps.
>
> "Scott Lewis" <slewis@composent.com> wrote in message
> news:d0lvht$28t$1@www.eclipse.org...
>
>>Greetings all,
>>
>>I am the project lead for the Eclipse Communications Framework technollgy
>>project. We have occasion to want to use several open source libraries
>>to help us implement some open protocols that we wish to support (e.g.
>>SIP--session initiation protocol).
>>
>>Of course part of using libraries that we did not develop is to be able to
>>quickly find and evaluate these libraries...and verify the following kinds
>>of things:
>>
>>a) the license(s) that the library is distributed under are compatible
>>with the EPL
>>b) that the history (e.g. ownership and copyright structure) of all the
>>code and any attached resources (e.g. images/sounds, etc) is clear and
>>consistent
>>c) that the implementation is solid (of course)
>>d) that the source code is well structured
>>e) that the owners/original developers are in favor of redistribution via
>>an Eclipse Foundation project
>>f) that the source for the library is available either via the foundation
>>or via some other means (e.g. download via sourceforge, etc) with terms
>>that are compatible with EPL
>>
>>My questions to you:
>>
>>a) As foundation members, do you feel foundation committers generally
>>understand all the steps necessary to assure that a library can be used
>>with a given project while keeping all of Eclipse 'ip-clean'?
>>b) Are more/better tools desired to aid this process (e.g. some basic
>>filters to search through codebases for copyright notices, license
>>notices...for both EPL compatible and incompatible)? Other ideas?
>>c) Is there/could there be a table that includes all the 'popular' open
>>source licenses and their status WRT EPL compatibility? e.g. GPL - no,
>>MPL - yes, etc.
>>d) Would it be helpful to have a 'checklist' for technical people to use
>>to help them organize the questions for the library developers?
>>e) Would it be helpful to have a specific newsgroup or forum for
>>discussion/consideration of IP issues for library usage in foundation
>>projects?
>>e) What other things do people feel are needed to support the easy but
>>thorough IP evaluation of open source libraries?
>>
>>Thanksinadvance,
>>
>>Scott
>>
>>
>
>
>
|
|
|
| Re: IP Evaluation for Libraries: Processes and tools needed? [message #16774 is a reply to message #16770] |
Thu, 10 March 2005 03:52 |
Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
> I understand that this is the place to start for technical review. It
> is where we started (with our previous efforts for ECF), but unfortunately
> it doesn't have anything really to do with verifying the IP status pf
> library code (although it is relevant to c & d on my list below...I
> probably shouldn't have included c&d on this list, but too late).
Correct, but since we're chatting on the newsgroup I thought it made sense
to include this for completeness.
>
>>
>> 2) when it comes to license compatibility, one of the easiest things to
>> do is check for precedents. If its been approved before, odds are it will
>> be again. Check out the list in
>> http://www.eclipse.org/legal/epl/notice.html.
>
> Sure...this is what we did as well. But if precedence doesn't exist (most
> common case still) it doesn't necessarily make sense to exclude from
> consideration...so wouldn't a license compatibility matrix help?
Regardless of whether I thought attempting to create such a matrix is a good
idea, completing and maintaining a license matrix is well beyond the scope
of what we can do currently. To see an example of the work required to
complete such a task, take a look at
http://www.catb.org/~esr/faqs/Licensing-HOWTO.html or
http://mibsoftware.com/librock/lidesc/tags.htm. This is not something to
undertake lightly. The licenses whi
>
>>
>> 3) if/when the PMC approves, fill out the Contribution Questionnaire at
>> http://www.eclipse.org/legal/ContributionQuestionnairePart1- v1.0.htm. But
>> *please* do not expect an instantaneous approval. The due diligence
>> process takes days, if not weeks. Expecting approval in 24 hours just
>> gets everyone frustrated. If you have any questions about when you need
>> to fill out the form, read the preamble. It's a good start. If you have
>> any additional questions, send an email to emo@eclipse.org or
>> janet.campbell@eclipse.org. Janet is our brand-new full-time Manager of
>> IP. This is what she does for a living, and she is here to act as a
>> resource for the entire community.
>
> Right...I didn't mean to leave this out...obviously it's critical. I was
> just trying to identify what the project teams could do in support of
> Janet's/foundations work here...in order to avoid having the strategy be
> to just submit everything that could be considered to the contribution
> questionnaire...and thereby creating additional overload for
> Janet/foundation.
>
>>
>> 4) don't try to spend a lot of time checking into the provenance of the
>> code yourself. Odds are that you will be duplicating effort. Janet's job
>> is to do this. She may need to work with you to get answers to some
>> questions, but that is not the same thing as requiring the committer to
>> be responsible for the task. This needs to be a collaborative process.
>
> Maybe some additional input/tools to aid in the project team's 'due
> dilligence' prior to getting Janet involved will help? Clearly we don't
> want to duplicate effort...but if (e.g.) checking the code for
> incompatible licenses could be automated to 80% with some simple filtering
> tools that the project team could run then perhaps it would save effort on
> everyone's part? This is the kind of thing I was thinking about, but
> there may be other tools that would be more effective.
>
>>
>> The next issue which is what you have listed as (e) and (f) in your first
>> list. At the highest level (and yes I know there are execptions), these
>> two must be true if the package is under an EPL-compatible open source
>> license. We at Eclipse don't expect that our users will ask our
>> permission to use Eclipse. That's explicit in the terms of the CPL and
>> EPL. So if the package is open source, these questions should not
>> typically come up. The corollary of this is that it is strictly verbotten
>> to include a package in Eclipse which is *not* open source. That would
>> cause our users no end of grief. Not to mention the Foundation :-)
>
> So should the project teams be expected to approach the authors of the
> library with the question: will you object (legally or not) to having
> this library redistributed via the foundation? Is this a reasonable part
> of the project team's due dilligence for a library unders consideration?
> Or should this be left to Janet/foundation?
>
> I speak for myself, but I do feel that the project teams would be willing
> to do more under the rubric of 'due dilligence' prior to submitting the
> questionnaire...if it's clear *what that due dilligence should consist
> of*, and that due dilligence can be aided with technology (for the lazy
> among us), consultation with people who've been through such a process
> before, some interaction with Janet, etc. So I guess some clarification
> of what the project team's due diligence should optimally consist of,
> along with some resources to support that due dilligence (e.g. tools,
> communication aids, etc) would be desireable from my point of view.
>
> It seems that Jim Adam's responses to my initial list indicated some of
> the clarification, tools, communication aids might be welcome for some
> others...no? Does this seem reasonable?
>
> Scott
>
>
>>
>> I hope this helps.
>>
>> "Scott Lewis" <slewis@composent.com> wrote in message
>> news:d0lvht$28t$1@www.eclipse.org...
>>
>>>Greetings all,
>>>
>>>I am the project lead for the Eclipse Communications Framework technollgy
>>>project. We have occasion to want to use several open source libraries
>>>to help us implement some open protocols that we wish to support (e.g.
>>>SIP--session initiation protocol).
>>>
>>>Of course part of using libraries that we did not develop is to be able
>>>to quickly find and evaluate these libraries...and verify the following
>>>kinds of things:
>>>
>>>a) the license(s) that the library is distributed under are compatible
>>>with the EPL
>>>b) that the history (e.g. ownership and copyright structure) of all the
>>>code and any attached resources (e.g. images/sounds, etc) is clear and
>>>consistent
>>>c) that the implementation is solid (of course)
>>>d) that the source code is well structured
>>>e) that the owners/original developers are in favor of redistribution via
>>>an Eclipse Foundation project
>>>f) that the source for the library is available either via the foundation
>>>or via some other means (e.g. download via sourceforge, etc) with terms
>>>that are compatible with EPL
>>>
>>>My questions to you:
>>>
>>>a) As foundation members, do you feel foundation committers generally
>>>understand all the steps necessary to assure that a library can be used
>>>with a given project while keeping all of Eclipse 'ip-clean'?
>>>b) Are more/better tools desired to aid this process (e.g. some basic
>>>filters to search through codebases for copyright notices, license
>>>notices...for both EPL compatible and incompatible)? Other ideas?
>>>c) Is there/could there be a table that includes all the 'popular' open
>>>source licenses and their status WRT EPL compatibility? e.g. GPL - no,
>>>MPL - yes, etc.
>>>d) Would it be helpful to have a 'checklist' for technical people to use
>>>to help them organize the questions for the library developers?
>>>e) Would it be helpful to have a specific newsgroup or forum for
>>>discussion/consideration of IP issues for library usage in foundation
>>>projects?
>>>e) What other things do people feel are needed to support the easy but
>>>thorough IP evaluation of open source libraries?
>>>
>>>Thanksinadvance,
>>>
>>>Scott
>>>
>>>
>>
>>
|
|
|
| Re: IP Evaluation for Libraries: Processes and tools needed? [message #16778 is a reply to message #16774] |
Thu, 10 March 2005 03:53 |
Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Please ignore this post. I hit send too early. Complete version coming
shortly.
"Mike Milinkovich" <mike.milinkovich@eclipse.org> wrote in message
news:d0og9c$o4q$1@www.eclipse.org...
>
>> I understand that this is the place to start for technical review. It
>> is where we started (with our previous efforts for ECF), but
>> unfortunately it doesn't have anything really to do with verifying the IP
>> status pf library code (although it is relevant to c & d on my list
>> below...I probably shouldn't have included c&d on this list, but too
>> late).
>
> Correct, but since we're chatting on the newsgroup I thought it made sense
> to include this for completeness.
>
>>
>>>
>>> 2) when it comes to license compatibility, one of the easiest things to
>>> do is check for precedents. If its been approved before, odds are it
>>> will be again. Check out the list in
>>> http://www.eclipse.org/legal/epl/notice.html.
>>
>> Sure...this is what we did as well. But if precedence doesn't exist
>> (most common case still) it doesn't necessarily make sense to exclude
>> from consideration...so wouldn't a license compatibility matrix help?
>
> Regardless of whether I thought attempting to create such a matrix is a
> good idea, completing and maintaining a license matrix is well beyond the
> scope of what we can do currently. To see an example of the work required
> to complete such a task, take a look at
> http://www.catb.org/~esr/faqs/Licensing-HOWTO.html or
> http://mibsoftware.com/librock/lidesc/tags.htm. This is not something to
> undertake lightly. The licenses whi
>
>>
>>>
>>> 3) if/when the PMC approves, fill out the Contribution Questionnaire at
>>> http://www.eclipse.org/legal/ContributionQuestionnairePart1- v1.0.htm.
>>> But *please* do not expect an instantaneous approval. The due diligence
>>> process takes days, if not weeks. Expecting approval in 24 hours just
>>> gets everyone frustrated. If you have any questions about when you need
>>> to fill out the form, read the preamble. It's a good start. If you have
>>> any additional questions, send an email to emo@eclipse.org or
>>> janet.campbell@eclipse.org. Janet is our brand-new full-time Manager of
>>> IP. This is what she does for a living, and she is here to act as a
>>> resource for the entire community.
>>
>> Right...I didn't mean to leave this out...obviously it's critical. I was
>> just trying to identify what the project teams could do in support of
>> Janet's/foundations work here...in order to avoid having the strategy be
>> to just submit everything that could be considered to the contribution
>> questionnaire...and thereby creating additional overload for
>> Janet/foundation.
>>
>>>
>>> 4) don't try to spend a lot of time checking into the provenance of the
>>> code yourself. Odds are that you will be duplicating effort. Janet's job
>>> is to do this. She may need to work with you to get answers to some
>>> questions, but that is not the same thing as requiring the committer to
>>> be responsible for the task. This needs to be a collaborative process.
>>
>> Maybe some additional input/tools to aid in the project team's 'due
>> dilligence' prior to getting Janet involved will help? Clearly we don't
>> want to duplicate effort...but if (e.g.) checking the code for
>> incompatible licenses could be automated to 80% with some simple
>> filtering tools that the project team could run then perhaps it would
>> save effort on everyone's part? This is the kind of thing I was thinking
>> about, but there may be other tools that would be more effective.
>>
>>>
>>> The next issue which is what you have listed as (e) and (f) in your
>>> first list. At the highest level (and yes I know there are execptions),
>>> these two must be true if the package is under an EPL-compatible open
>>> source license. We at Eclipse don't expect that our users will ask our
>>> permission to use Eclipse. That's explicit in the terms of the CPL and
>>> EPL. So if the package is open source, these questions should not
>>> typically come up. The corollary of this is that it is strictly
>>> verbotten to include a package in Eclipse which is *not* open source.
>>> That would cause our users no end of grief. Not to mention the
>>> Foundation :-)
>>
>> So should the project teams be expected to approach the authors of the
>> library with the question: will you object (legally or not) to having
>> this library redistributed via the foundation? Is this a reasonable part
>> of the project team's due dilligence for a library unders consideration?
>> Or should this be left to Janet/foundation?
>>
>> I speak for myself, but I do feel that the project teams would be willing
>> to do more under the rubric of 'due dilligence' prior to submitting the
>> questionnaire...if it's clear *what that due dilligence should consist
>> of*, and that due dilligence can be aided with technology (for the lazy
>> among us), consultation with people who've been through such a process
>> before, some interaction with Janet, etc. So I guess some clarification
>> of what the project team's due diligence should optimally consist of,
>> along with some resources to support that due dilligence (e.g. tools,
>> communication aids, etc) would be desireable from my point of view.
>>
>> It seems that Jim Adam's responses to my initial list indicated some of
>> the clarification, tools, communication aids might be welcome for some
>> others...no? Does this seem reasonable?
>>
>> Scott
>>
>>
>>>
>>> I hope this helps.
>>>
>>> "Scott Lewis" <slewis@composent.com> wrote in message
>>> news:d0lvht$28t$1@www.eclipse.org...
>>>
>>>>Greetings all,
>>>>
>>>>I am the project lead for the Eclipse Communications Framework
>>>>technollgy project. We have occasion to want to use several open
>>>>source libraries to help us implement some open protocols that we wish
>>>>to support (e.g. SIP--session initiation protocol).
>>>>
>>>>Of course part of using libraries that we did not develop is to be able
>>>>to quickly find and evaluate these libraries...and verify the following
>>>>kinds of things:
>>>>
>>>>a) the license(s) that the library is distributed under are compatible
>>>>with the EPL
>>>>b) that the history (e.g. ownership and copyright structure) of all the
>>>>code and any attached resources (e.g. images/sounds, etc) is clear and
>>>>consistent
>>>>c) that the implementation is solid (of course)
>>>>d) that the source code is well structured
>>>>e) that the owners/original developers are in favor of redistribution
>>>>via an Eclipse Foundation project
>>>>f) that the source for the library is available either via the
>>>>foundation or via some other means (e.g. download via sourceforge, etc)
>>>>with terms that are compatible with EPL
>>>>
>>>>My questions to you:
>>>>
>>>>a) As foundation members, do you feel foundation committers generally
>>>>understand all the steps necessary to assure that a library can be used
>>>>with a given project while keeping all of Eclipse 'ip-clean'?
>>>>b) Are more/better tools desired to aid this process (e.g. some basic
>>>>filters to search through codebases for copyright notices, license
>>>>notices...for both EPL compatible and incompatible)? Other ideas?
>>>>c) Is there/could there be a table that includes all the 'popular' open
>>>>source licenses and their status WRT EPL compatibility? e.g. GPL - no,
>>>>MPL - yes, etc.
>>>>d) Would it be helpful to have a 'checklist' for technical people to use
>>>>to help them organize the questions for the library developers?
>>>>e) Would it be helpful to have a specific newsgroup or forum for
>>>>discussion/consideration of IP issues for library usage in foundation
>>>>projects?
>>>>e) What other things do people feel are needed to support the easy but
>>>>thorough IP evaluation of open source libraries?
>>>>
>>>>Thanksinadvance,
>>>>
>>>>Scott
>>>>
>>>>
>>>
>>>
>
|
|
|
| Re: IP Evaluation for Libraries: Processes and tools needed? [message #16781 is a reply to message #16770] |
Thu, 10 March 2005 04:13 |
Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
"Scott Lewis" <slewis@composent.com> wrote in message
news:422FBF0C.1050802@composent.com...
> I understand that this is the place to start for technical review. It is
> where we started (with our previous efforts for ECF), but unfortunately it
> doesn't have anything really to do with verifying the IP status pf library
> code (although it is relevant to c & d on my list below...I probably
> shouldn't have included c&d on this list, but too late).
Correct, but since we're chatting on the newsgroup I thought it made sense
to include this for completeness.
>
>>
>> 2) when it comes to license compatibility, one of the easiest things to
>> do is check for precedents. If its been approved before, odds are it will
>> be again. Check out the list in
>> http://www.eclipse.org/legal/epl/notice.html.
>
> Sure...this is what we did as well. But if precedence doesn't exist (most
> common case still) it doesn't necessarily make sense to exclude from
> consideration...so wouldn't a license compatibility matrix help?
Regardless of whether I thought attempting to create such a matrix is a good
idea, completing and maintaining a license matrix is well beyond the scope
of what we can do currently. To see an example of the work required to
complete such a task, take a look at
http://www.catb.org/~esr/faqs/Licensing-HOWTO.html or
http://mibsoftware.com/librock/lidesc/tags.htm. This is not something to
undertake lightly. Nor should it be undertaken without expert professional
assistance.
BTW - The licenses which we have on our current list covers the vast
majority of the inbound requests I have seen since joining.
>> 3) if/when the PMC approves, fill out the Contribution Questionnaire at
>> http://www.eclipse.org/legal/ContributionQuestionnairePart1- v1.0.htm. But
>> *please* do not expect an instantaneous approval. The due diligence
>> process takes days, if not weeks. Expecting approval in 24 hours just
>> gets everyone frustrated. If you have any questions about when you need
>> to fill out the form, read the preamble. It's a good start. If you have
>> any additional questions, send an email to emo@eclipse.org or
>> janet.campbell@eclipse.org. Janet is our brand-new full-time Manager of
>> IP. This is what she does for a living, and she is here to act as a
>> resource for the entire community.
>
> Right...I didn't mean to leave this out...obviously it's critical. I was
> just trying to identify what the project teams could do in support of
> Janet's/foundations work here...in order to avoid having the strategy be
> to just submit everything that could be considered to the contribution
> questionnaire...and thereby creating additional overload for
> Janet/foundation.
Thanks, I appreciate that. I'm sure Janet does as well :-) But the flip
side is that we don't *necessarily* want developers spending time on this
stuff either. In my experience, most committers would rather write code than
wade through IP questions. The idea is to have a resource at the Foundation
who to the degree possible can relieve committers of this burden.
>> The next issue which is what you have listed as (e) and (f) in your first
>> list. At the highest level (and yes I know there are execptions), these
>> two must be true if the package is under an EPL-compatible open source
>> license. We at Eclipse don't expect that our users will ask our
>> permission to use Eclipse. That's explicit in the terms of the CPL and
>> EPL. So if the package is open source, these questions should not
>> typically come up. The corollary of this is that it is strictly verbotten
>> to include a package in Eclipse which is *not* open source. That would
>> cause our users no end of grief. Not to mention the Foundation :-)
>
> So should the project teams be expected to approach the authors of the
> library with the question: will you object (legally or not) to having
> this library redistributed via the foundation? Is this a reasonable part
> of the project team's due dilligence for a library unders consideration?
> Or should this be left to Janet/foundation?
If you think that the license is open source, leave it to the Foundation. If
you don't think the license is open source, keep searching for an
alternative.
If you want to contact the other party to have a technical chat, or just
because you think it is the courteous thing to do of course you can do that.
But to be honest I don't even really understand the notion of asking for
permission to distribute something which has been made available under an
open source license. The license itself provides explicit permission to
re-distribute.
> It seems that Jim Adam's responses to my initial list indicated some of
> the clarification, tools, communication aids might be welcome for some
> others...no? Does this seem reasonable?
I totally agree that we can and should do more. But in many cases there is
already documentation available which does not get read. (I don't mean to
imply that this is true in your case.) Committers should check out the
committer guidelines (http://www.eclipse.org/legal/committerguidelines.html)
once in a blue moon to refresh their memory. And any committer who has never
read them really really should. Project leaders should have a reasonable
mastery of the content on the "legal stuff"
(http://www.eclipse.org/legal/main.html) page.
I agree that some of this content need freshening, but there is also some
good and relevant content there.
/mike
|
|
|
| Re: IP Evaluation for Libraries: Processes and tools needed? [message #16784 is a reply to message #16781] |
Thu, 10 March 2005 04:49 |
| Eclipse User |
|
|
|
Originally posted by: slewis.composent.com
Mike Milinkovich wrote:
>Committers should check out the
> committer guidelines (http://www.eclipse.org/legal/committerguidelines.html)
> once in a blue moon to refresh their memory.
>And any committer who has never
> read them really really should. Project leaders should have a reasonable
> mastery of the content on the "legal stuff"
> (http://www.eclipse.org/legal/main.html) page.
Right...both of these are definately on my 're-read 3-4 times a year'
category...but maybe they should be required reading for committer
status refresh? (you didn't hear that from me...I'll probably be
pummelled by committers for suggesting that, but oh well...should start
early so I get used to it ;-).
>
> I agree that some of this content need freshening, but there is also some
> good and relevant content there.
Of course...it's like a stroll through the NY Times Sunday Book Section
;-). Just kidding. Of course you are right...and I agree that it's
very important for all to read through repeatedly (particularly the
License Compatibility, Due Dilligence, and Third Party Content
sections...apropos our topic here).
Scott
|
|
|
Goto Forum:
Current Time: Thu Apr 25 07:25:43 GMT 2024
Powered by FUDForum. Page generated in 0.03828 seconds |
] 
Search
Help
Register
Login
Home
