www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Writing spec code for the OSGi Alliance within the ASF
Date Fri, 20 Jan 2017 10:51:44 GMT
The discussion came up on dev@felix.a.o

In some cases people are writing code inside the ASF as part of spec work
for the OSGi Alliance.  The code written is copyrighted to the OSGi
Alliance and supposed to be made available through a specific license [1].
Is that compatible ?

[1] https://www.osgi.org/distribution-and-feedback-license/

---------- Forwarded message ----------
From: Guillaume Nodet <gnodet@apache.org>
Date: 2017-01-20 11:42 GMT+01:00
Subject: Re: Implementation of unreleased spec and community
To: dev@felix.apache.org




2017-01-20 11:26 GMT+01:00 Neil Bartlett <njbartlett@gmail.com>:

>
> > On 20 Jan 2017, at 10:12, Guillaume Nodet <gnodet@apache.org> wrote:
> >
> > 2017-01-20 10:58 GMT+01:00 Guillaume Nodet <gnodet@apache.org <mailto:
> gnodet@apache.org>>:
> >
> >>
> >>
> >> 2017-01-19 19:36 GMT+01:00 Timothy Ward <timothyjward@apache.org>:
> >>
> >>> At this point I’d also like to re-affirm that the OSGi RFC documents
> are
> >>> public, and that there is a public feedback mechanism for RFC bugs. As
> the
> >>> holder of the pen for Transaction Control, the JAX-RS whiteboard, and
> the
> >>> JPA service updates I can truthfully say that community discussion and
> >>> feedback has influenced the direction of those RFCs/specifications, not
> >>> just the converter.
> >>>
> >>> As David says below, you can gain increased control over the direction
> of
> >>> things anywhere by becoming a member/committer/employee. Committers in
> >>> Apache Aries have ample opportunity to review and discuss the many
> >>> implementations built there, just as they do in Felix. This right
> applies
> >>> both before and after the release of the specification. What Apache
> >>> Committers can’t do is make changes to an OSGi RFC/spec, for that they
> need
> >>> to lobby an OSGi member.
> >>
> >>
> >> I have no problems with the above.
> >>
> >>
> >>> This is exactly the same for a committer in Eclipse, on Github, or in a
> >>> private company, so it leaves Apache committers just as equal as
> everyone
> >>> else.
> >>
> >>
> >> I don't care about how Eclipse or Github project are operated.  We're
> >> talking about Apache projects and there are rules.  One of them is that
> >> committers are considered equal.
> >>
> >>
> >>> The main difference here is that there are a lot of OSGi members who
> >>> believe in Apache, and therefore contribute as committers. Are we
> really
> >>> saying that those committers should be disallowed because they are OSGi
> >>> members and therefore have “more power”?
> >>>
> >>
> >> Not disallowed, but yes, they should not do something within the ASF
> that
> >> other committers who are not OSGi members can't do.
> >> So to be clear: if any committer want to work on an implementation of an
> >> RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi
> >> members or not.
> >> If an OSGi member want to work on spec design within the ASF bounds, I
> >> think that's not fine.   In particular, if someone propose to develop
> some
> >> code to implement an RFC when the API from the developped and later
> >> introduced back into the RFC document, I think that's definitely spec
> work,
> >> and should not be done within the RFC.
> >>
> >> To be crystal clear, I have a problem with Ray willing to bring code for
> >> implementing rfc-193 in Aries, when the code that he wants to bring
> >> contains lots of things that are not reflected in the RFC document and
> the
> >> opposite.  Ray and David explained that the RFC document will be
> updated in
> >> the coming weeks to reflect those changes.  This is definitely spec
> work,
> >> and that's fine, but I don't think it should happen at Apache.  Again,
> it's
> >> a timing problem wrt to changes in the document and changes in the code
> :
> >> if the code is changes first by the spec lead, and later validated on
> >> during OSGi meetings and later integrated into the spec document and
> made
> >> public, I definitely see that as spec work, not as building an
> >> implementation, and imho this is unfair to other committers because it
> does
> >> not follow the ASF rules.  It's certainly open source, but not the
> Apache
> >> way.
> >>
> >
> > And btw, even from a legal ASF pov, I'm not sure how things hold.  People
> > are writing code copyrighted to the OSGi Alliance directly in the ASF…
>
>
> And when *you* write code in the ASF, you own the copyright to that code.
> Apache does not require or expect that copyright ownership of the code is
> transferred to the ASF, only that it is licensed under the terms of the
> ASL. The fact that OSGi Alliance may be the copyright holder of some code
> does not present any problems.
>
> Though maybe you shouldn’t seek legal advice on a developer mailing list
> ;-)
>

Well, the code does not seem to comply to the ASF rules at leat:
  https://www.apache.org/legal/src-headers.html


   1. This section refers only to works submitted directly to the ASF by
   the copyright owner or owner's agent.
   2. This section refers only to works submitted directly to the ASF by
   the copyright owner or owner's agent.
   3. If the source file is submitted with a copyright notice included in
   it, the copyright owner (or owner's agent) must either:
      1. remove such notices, or
      2. move them to the NOTICE file associated with each applicable
      project release, or
      3. provide written permission for the ASF to make such removal or
      relocation of the notices.
   4. Each source file should include the following license header -- note
   that there should be no copyright notice in the header:



Committers do sign an ICLA or CCLA.  In both cases, there's a Grant of
Copyright License whereby the owner gives to the ASF "a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable   copyright
license to reproduce, prepare derivative works of,   publicly display,
publicly perform, sublicense, and distribute Your   Contributions and such
derivative works."    I suppose that would be different if the code would
be written elsewhere and later imported in the ASF.
Afaik, the OSGi rfc / spec work is covered by the Distribution and Feedback
License whereby "The OSGi Alliance hereby grants you a limited copyright
license to copy and display this document (the “Distribution”) in any
medium without fee or royalty. This Distribution license is exclusively for
the purpose of reviewing and providing feedback to the OSGi Alliance. "
I'm definitely no lawyer, but again, not sure how everything holds together.
But you're right, given I'm no layer, I'll ask legal about that.



>
> >
> >
> >>
> >>
> >>>
> >>> Finally, there are a lot of projects and/or components in Open Source
> >>> (including Apache) that are written by a single committer, typically
> the
> >>> person with the itch to scratch. Only If that committer tries to
> prevent
> >>> discussion about, or changes to, that code is there a problem for the
> >>> community. To my knowledge this does not apply to any of the
> components in
> >>> Apache Aries or Apache Felix.
> >>>
> >>
> >> A piece of code being developed by a single person is definitely not a
> >> good thing within the ASF.  Again, the ASF operates with community over
> >> code mantra and requires diversity within a project to avoid
> dictatorship
> >> and to ensure that the code development is overseen and can be
> maintained
> >> if one people is going away.  Having some code being developed by a
> single
> >> person certainly does not help. The fact that it has almost always been
> the
> >> case for a bunch of subprojects in Felix or Aries does not mean it's
> >> healthy nor good.   But this is slightly mitigated by the fact that over
> >> time, people tend to jump and fix things when they need.
> >>
> >> Obviously, if that person would try to prevent discussion or code
> changes,
> >> that would be definitely a critical problem, but I haven't seen such a
> >> behavior.
> >>
> >>
> >>>
> >>> Best Regards,
> >>>
> >>> Tim Ward
> >>>
> >>>> On 19 Jan 2017, at 17:32, David Leangen <osgi@leangen.net> wrote:
> >>>>
> >>>>>> Ray has listed a number of things that have been implemented
during
> >>> the
> >>>>>> past few months.  All of them have been written by a single
> committer
> >>> who
> >>>>>> also happen to be the one modifying the spec document.
> >>>>>>
> >>>>>>
> >>>>> This is factually incorrect at least for the Converter implementation
> >>> at
> >>>>> Felix. Just look at the commit history for commits done on behalf
of
> >>>>> community members and also check the mailing list for discussions
> that
> >>>>> definitely provided great feedback on the work done.
> >>>>
> >>>> I have been doing a very tiny bit of work on the Converter as a double
> >>> outsider (non committer in Felix, and non OSGi member).
> >>>>
> >>>> I completely rely on others to accept my contributions and
> suggestions,
> >>> making me a kind of second class citizen. It does work, but I need to
> >>> either (i) become a first class citizen either by merit or paying fees,
> >>> depending on the organisation, or (ii) accept my dependence on the
> goodwill
> >>> of others. Currently I have a de facto sponsor who has been very
> attentive
> >>> to my questions and contributions, so (ii) is working out well enough.
> If
> >>> it didn’t work out, could always fall back on option (i).
> >>>>
> >>>> So I can understand the frustrations and agree that there is a bit of
> a
> >>> grey area, but at the same time I understand that in the end I have the
> >>> same opportunities as everybody else. In this case, I am not
> willing/able
> >>> to “pay the price” for full citizenship, so I don’t feel I have the
> right
> >>> to complain.
> >>>>
> >>>>
> >>>> Just my 2¥.
> >>>>
> >>>> Cheers,
> >>>> =David
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> ------------------------
> >> Guillaume Nodet
> >>
> >>
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
>
>


-- 
------------------------
Guillaume Nodet




-- 
------------------------
Guillaume Nodet

Mime
View raw message