[go: up one dir, main page]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

License problem #2

Closed
garbas opened this issue Aug 24, 2011 · 6 comments
Closed

License problem #2

garbas opened this issue Aug 24, 2011 · 6 comments
Assignees
Milestone

Comments

@garbas
Copy link
Contributor
garbas commented Aug 24, 2011

As said before on mailing list there are some issues with license. i send email to list and all involved trying to get their attention so we move on with this boring task.

My proposition is to put everything under BSD license and give ownership to Plone Fundation:

  • "OWNER" = Plone Fundation
  • "YEAR" = 2011

List of contributors that need to confirm this (in comment or on mailing list):

  • Max M. (+1)
  • Andreas Zeidler
  • Lennart Regebro (+1)
  • Martijn Fassen
  • Sidnei da Silva
  • Wichert Akkerman
  • Pavel Repin (+1)
  • Eric Hanchrow (+1)
  • George V. Reilly (+1)
  • Johannes Raggam (+1)

My opinion: Personally don't care about which license do we choose or who is the owner as long as it is "OSI approved" and owner some open source fundation.

If you have you own proposition please put it in comment so we discuss it.

@ghost ghost assigned garbas Aug 24, 2011
@regebro
Copy link
Contributor
regebro commented Aug 24, 2011

I don't care much, but prefer MIT licensing.

On Wed, Aug 24, 2011 at 22:52, garbas
reply@reply.github.com
wrote:

As said before on mailing list there are some issues with license. i send email to list and all involved trying to get their attention so we move on with this boring task.

My proposition is to put everything under BSD license and give ownership to Plone Fundation:
 - = Plone Fundation
 - = 2011

List of contributors that need to confirm this (in comment or on mailing list):
 - Max M.
 - Andreas Zeidler
 - Lennart Regebro
 - Martijn Fassen
 - Sidnei da Silva
 - Wichert Akkerman
 - Pavel Repin
 - Eric Hanchrow
 - George V. Reilly
 - Johannes Raggam

My opinion: Personally don't care about which license do we choose or who is the owner as long as it is "OSI approved" and owner some open source fundation.

If you have you own proposition please put it in comment so we discuss it.

Reply to this email directly or view it on GitHub:
#2

@georgevreilly
Copy link
Contributor

I don't much care either. BSD is fine with me.

@offby1
Copy link
Contributor
offby1 commented Aug 25, 2011

BSD is also fine with me.

@thet
Copy link
Member
thet commented Aug 25, 2011

I agree, BSD is fine for me.

@garbas
Copy link
Contributor Author
garbas commented Aug 25, 2011

to my email, confirmation from Max...

I don't care much about what licence it is, as long as its free and open. There has been discussion about it before. I think we all felt the same way.

And as I said. you don't have to ask me about anything. Just glad it lives on.

@paxan
Copy link
Contributor
paxan commented Sep 3, 2011

I am fine with BSD. Thanks.

@garbas garbas closed this as completed in f469e86 Feb 27, 2012
jperkin pushed a commit to TritonDataCenter/pkgsrc-legacy that referenced this issue Dec 9, 2013
Changes in version 3.0
======================

API Change
----------

Since version we unified to icalendar de/serialization API to use only to_ical
(for writing an ical string from the internal representation) and from_ical
(for parsing an ical string into the internal representation).

to_ical is now used instead of the methods ical, string, as_string and instead
of string casting via __str__ and str.

from_ical is now used instead of from_string.

This change is a requirement for future Python 3 compatibility. Please update
your code to reflect to the new API.

Timezone support
----------------

Timezones are now fully supported in icalendar for serialization and
deserialization. We use the pytz library for timezone components of datetime
instances. The timezone identifiers must be valid pytz respectively Olson
database timezone identifiers. This can be a problem for 'GMT' identifiers,
which are not defined in the Olson database.

Instead of the own UTC tzinfo implementation we use pytz UTC tzinfo object now.


About this fork which is not a fork anymore
===========================================

Aim of this fork (not fork anymore, read further) was to bring this package up
to date with latest icalendar `RFC`_ specification as part of
`plone.app.event`_ project which goal is to bring recurrent evens to `Plone`_.

After some thoughts we (Plone developers involved with `plone.app.event`_) send
a suggestion to icalendar-dev@codespeak.net to take over mainaining of
`icalendar`_. Nobody object and since version 2.2 we are back to development.

.. _`icalendar`: http://pypi.python.org/pypi/icalendar
.. _`plone.app.event`: http://github.com/collective/plone.app.event
.. _`Plone`: http://plone.org
.. _`pytz`: http://pypi.python.org/pypi/pytz
.. _`setuptools`: http://pypi.python.org/pypi/setuptools
.. _`RFC`: http://www.ietf.org/rfc/rfc5545.txt
.. _`BSD`: collective/icalendar#2


3.1

    Make sure parameters to certain properties propagate to the
    ical output. [kanarip]
    Re-include doctests. [rnix]
    endure correct datatype at instance creation time in prop.vCalAddress
    and prop.vText. [rnix]
    Apply TZID parameter to datetimes parsed from RECURRENCE-ID
    [dbstovall]
    Localize datetimes for timezones to avoid DST transition errors.
    [dbstovall]
    Allow UTC-OFFSET property value data types in seconds, which
    follows RFC5545 specification. [nikolaeff]
    Remove utctz and normalized_timezone methods to simplify the
    codebase. The methods were too tiny to be useful and just used
    at one place. [thet]
    When using Component.add() to add icalendar properties, force
    a value conversion to UTC for CREATED, DTSTART and LAST-MODIFIED.
    The RFC expects UTC for those properties. [thet]
    Removed last occurrences of old API (from_string). [Rembane]
    Add
    listing. For example when parsing a text/calendar text including
    multiple components (e.g. a VCALENDAR with 5 VEVENTs), the
    previous situation required us to look over all properties in
    VEVENTs even if we just want the properties under the VCALENDAR
    component (VERSION, PRODID, CALSCALE, METHOD). [dmikurube]
    All unit tests fixed. [mikaelfrykholm]

3.0.1b2 (2012-03-01)

    For all TZID parameters in DATE-TIME properties, use timezone
    identifiers (e.g. Europe/Vienna) instead of timezone names
    (e.g. CET), as required by RFC5545. Timezone names are used
    together with timezone identifiers in the Timezone components.
    [thet]
    Timezone parsing, issues and test fixes. [mikaelfrykholm,
    garbas, tgecho]
    Since we use pytz for timezones, also use UTC tzinfo object
    from the pytz library instead of own implementation. [thet]

3.0.1b1 (2012-02-24)

    Update Release information. [thet]

3.0

    Add API for proper Timezone support. Allow creating ical
    DATE-TIME strings with timezone information from Python datetimes
    with pytz based timezone information and vice versa. [thet]
    Unify API to only use to_ical and from_ical and remove string
    casting as a requirement for Python 3 compatibility: New:
    to_ical. Old: ical, string, as_string and string casting via
    __str__ and str. New: from_ical. Old: from_string. [thet]
jsonn pushed a commit to jsonn/pkgsrc that referenced this issue Oct 11, 2014
Changes in version 3.0
======================

API Change
----------

Since version we unified to icalendar de/serialization API to use only to_ical
(for writing an ical string from the internal representation) and from_ical
(for parsing an ical string into the internal representation).

to_ical is now used instead of the methods ical, string, as_string and instead
of string casting via __str__ and str.

from_ical is now used instead of from_string.

This change is a requirement for future Python 3 compatibility. Please update
your code to reflect to the new API.

Timezone support
----------------

Timezones are now fully supported in icalendar for serialization and
deserialization. We use the pytz library for timezone components of datetime
instances. The timezone identifiers must be valid pytz respectively Olson
database timezone identifiers. This can be a problem for 'GMT' identifiers,
which are not defined in the Olson database.

Instead of the own UTC tzinfo implementation we use pytz UTC tzinfo object now.


About this fork which is not a fork anymore
===========================================

Aim of this fork (not fork anymore, read further) was to bring this package up
to date with latest icalendar `RFC`_ specification as part of
`plone.app.event`_ project which goal is to bring recurrent evens to `Plone`_.

After some thoughts we (Plone developers involved with `plone.app.event`_) send
a suggestion to icalendar-dev@codespeak.net to take over mainaining of
`icalendar`_. Nobody object and since version 2.2 we are back to development.

.. _`icalendar`: http://pypi.python.org/pypi/icalendar
.. _`plone.app.event`: http://github.com/collective/plone.app.event
.. _`Plone`: http://plone.org
.. _`pytz`: http://pypi.python.org/pypi/pytz
.. _`setuptools`: http://pypi.python.org/pypi/setuptools
.. _`RFC`: http://www.ietf.org/rfc/rfc5545.txt
.. _`BSD`: collective/icalendar#2


3.1

    Make sure parameters to certain properties propagate to the
    ical output. [kanarip]
    Re-include doctests. [rnix]
    endure correct datatype at instance creation time in prop.vCalAddress
    and prop.vText. [rnix]
    Apply TZID parameter to datetimes parsed from RECURRENCE-ID
    [dbstovall]
    Localize datetimes for timezones to avoid DST transition errors.
    [dbstovall]
    Allow UTC-OFFSET property value data types in seconds, which
    follows RFC5545 specification. [nikolaeff]
    Remove utctz and normalized_timezone methods to simplify the
    codebase. The methods were too tiny to be useful and just used
    at one place. [thet]
    When using Component.add() to add icalendar properties, force
    a value conversion to UTC for CREATED, DTSTART and LAST-MODIFIED.
    The RFC expects UTC for those properties. [thet]
    Removed last occurrences of old API (from_string). [Rembane]
    Add
    listing. For example when parsing a text/calendar text including
    multiple components (e.g. a VCALENDAR with 5 VEVENTs), the
    previous situation required us to look over all properties in
    VEVENTs even if we just want the properties under the VCALENDAR
    component (VERSION, PRODID, CALSCALE, METHOD). [dmikurube]
    All unit tests fixed. [mikaelfrykholm]

3.0.1b2 (2012-03-01)

    For all TZID parameters in DATE-TIME properties, use timezone
    identifiers (e.g. Europe/Vienna) instead of timezone names
    (e.g. CET), as required by RFC5545. Timezone names are used
    together with timezone identifiers in the Timezone components.
    [thet]
    Timezone parsing, issues and test fixes. [mikaelfrykholm,
    garbas, tgecho]
    Since we use pytz for timezones, also use UTC tzinfo object
    from the pytz library instead of own implementation. [thet]

3.0.1b1 (2012-02-24)

    Update Release information. [thet]

3.0

    Add API for proper Timezone support. Allow creating ical
    DATE-TIME strings with timezone information from Python datetimes
    with pytz based timezone information and vice versa. [thet]
    Unify API to only use to_ical and from_ical and remove string
    casting as a requirement for Python 3 compatibility: New:
    to_ical. Old: ical, string, as_string and string casting via
    __str__ and str. New: from_ical. Old: from_string. [thet]
niccokunzmann pushed a commit that referenced this issue Sep 28, 2022
…ssue_345

Jacadzaca test restructure issue 345
niccokunzmann pushed a commit that referenced this issue Nov 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants