| [LICENSE] - Clarify EPL Licensing Terms 'human readable' [message #3169] |
Wed, 13 October 2004 03:38  |
Eclipse User |
|
|
|
Originally posted by: ilias.lazaridis.com
[followup to .foundation]
Eclipse should inform the community with 'human readable' short forms of the CPL/EPL license (see footnote [1] as an example).
This would ensure that users, developers, committers and especially Project Leads know about the essential mechanics of the EPL license.
This way confusion and wrong expectations could be avoided (and thus frustrating 'wake-up-experience', which has a negative influence on the image of eclipse).
Documents & faq's are available, but not everyone reads them fully or has the time to extract the complete essence.
-
Some example entries for a compact document:
- If you modify _and_ distribute an EPL licenced plugin, you are *obligated*
- to make the source publicly available
- to keep the source easy modifiable to other programmers, which means essentially
- to have no dependencies to private code
- to included a build process (prefered the original one)
- target: plugin which can be used to replace original plugin
- If you create _and_ distribute an commercial add-in plugin...
[...]
-
An practical example for this is the webtools project:
http://www.eclipse.org/newsportal/article.php?id=1523&gr oup=eclipse.webtools
-
Many time gets lost due to inefficient information of the community.
-
[1]
http://creativecommons.org/licenses/by/2.0/
..
--
http://lazaridis.com
|
|
|
| Re: [LICENSE] - Clarify EPL Licensing Terms 'human readable' [message #14970 is a reply to message #3169] |
Wed, 16 February 2005 16:54  |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
No, Eclipse shouldn't. The license is the license. Any other words about
the license are not the license. For example, in your sample entries you
have terms that go well beyond the license. In fact, any such document
that people would find useful would have to go beyond the license, e.g.,
explaining terms like 'derived work' which are fundamentally
inexplicable in "human readable" terms.
Bob Foster
ilias wrote:
> [followup to .foundation]
>
> Eclipse should inform the community with 'human readable' short forms of
> the CPL/EPL license (see footnote [1] as an example).
>
> This would ensure that users, developers, committers and especially
> Project Leads know about the essential mechanics of the EPL license.
>
> This way confusion and wrong expectations could be avoided (and thus
> frustrating 'wake-up-experience', which has a negative influence on the
> image of eclipse).
>
> Documents & faq's are available, but not everyone reads them fully or
> has the time to extract the complete essence.
>
> -
>
> Some example entries for a compact document:
>
> - If you modify _and_ distribute an EPL licenced plugin, you are
> *obligated*
> - to make the source publicly available
> - to keep the source easy modifiable to other programmers, which means
> essentially
> - to have no dependencies to private code
> - to included a build process (prefered the original one)
> - target: plugin which can be used to replace original plugin
>
> - If you create _and_ distribute an commercial add-in plugin...
>
> [...]
>
> -
>
> An practical example for this is the webtools project:
>
> http://www.eclipse.org/newsportal/article.php?id=1523&gr oup=eclipse.webtools
>
>
> -
>
> Many time gets lost due to inefficient information of the community.
>
> -
>
> [1]
> http://creativecommons.org/licenses/by/2.0/
>
> .
>
|
|
|
| Re: [LICENSE] - Clarify EPL Licensing Terms 'human readable' [message #14987 is a reply to message #3169] |
Thu, 17 February 2005 02:10 |
| Eclipse User |
|
|
|
Originally posted by: Lamont_Gilbert.rigidsoftware.com
Yes im not so sure about that either. The FAQ is the attempt at being
human readable, and I feel like the FAQ is the intent but does not
necessarily agree with the license anyway. That will happen anytime you
need to express things in two different ways...
CL
ilias wrote:
> [followup to .foundation]
>
> Eclipse should inform the community with 'human readable' short forms of
> the CPL/EPL license (see footnote [1] as an example).
>
> This would ensure that users, developers, committers and especially
> Project Leads know about the essential mechanics of the EPL license.
>
> This way confusion and wrong expectations could be avoided (and thus
> frustrating 'wake-up-experience', which has a negative influence on the
> image of eclipse).
>
> Documents & faq's are available, but not everyone reads them fully or
> has the time to extract the complete essence.
>
> -
>
> Some example entries for a compact document:
>
> - If you modify _and_ distribute an EPL licenced plugin, you are
> *obligated*
> - to make the source publicly available
> - to keep the source easy modifiable to other programmers, which means
> essentially
> - to have no dependencies to private code
> - to included a build process (prefered the original one)
> - target: plugin which can be used to replace original plugin
>
> - If you create _and_ distribute an commercial add-in plugin...
>
> [...]
>
> -
>
> An practical example for this is the webtools project:
>
> http://www.eclipse.org/newsportal/article.php?id=1523&gr oup=eclipse.webtools
>
>
> -
>
> Many time gets lost due to inefficient information of the community.
>
> -
>
> [1]
> http://creativecommons.org/licenses/by/2.0/
>
> .
>
|
|
|
Powered by
FUDForum. Page generated in 0.27440 seconds
] 
Search
Help
Register
Login
Home
