incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: JSON License and Apache Projects
Date Thu, 24 Nov 2016 14:19:21 GMT
The Apache ManifoldCF project got an official Legal ruling on the json
license and accepted it many years ago.

Thanks,
Karl



On Thu, Nov 24, 2016 at 7:11 AM, Guillaume Laforge <glaforge@gmail.com>
wrote:

> And Apache Groovy also has some great JSON support as well, with a super
> fast parser, and serializer as well.
> So there's choice at Apache regarding JSON :-D
>
> On Thu, Nov 24, 2016 at 12:56 PM, Hendrik Dev <hendrikdev22@gmail.com>
> wrote:
>
> > and of course there is also Apache Johnzon ;-)
> > http://johnzon.apache.org/
> >
> > On Thu, Nov 24, 2016 at 10:21 AM, Stephan Ewen <sewen@apache.org> wrote:
> > > Just to be on the safe side:
> > >
> > > If project X depends on another project Y that uses json.org (and thus
> > > project X has json.org as a transitive dependency) is it sufficient to
> > > exclude the transitive json.org dependency in the reference to project
> > Y?
> > >
> > > Something like that:
> > >
> > > <dependency>
> > >   <groupId>org.apache.hive.hcatalog</groupId>
> > >   <artifactId>hcatalog-core</artifactId>
> > >   <version>0.12.0</version>
> > >   <exclusions>
> > >     <exclusion>
> > >       <groupId>org.json</groupId>
> > >       <artifactId>json</artifactId>
> > >     </exclusion>
> > >   </exclusions>
> > > </dependency>
> > >
> > > Thanks,
> > > Stephan
> > >
> > >
> > > On Thu, Nov 24, 2016 at 10:00 AM, Jochen Theodorou <blackdrag@gmx.org>
> > > wrote:
> > >
> > >> is that library able to deal with the jdk9 module system?
> > >>
> > >>
> > >> On 24.11.2016 02:16, James Bognar wrote:
> > >>
> > >>> Shameless plug for Apache Juneau that has a cleanroom implementation
> > of a
> > >>> JSON serializer and parser in context of a common serialization API
> > that
> > >>> includes a variety of serialization languages for POJOs.
> > >>>
> > >>> On Wed, Nov 23, 2016 at 8:10 PM Ted Dunning <ted.dunning@gmail.com>
> > >>> wrote:
> > >>>
> > >>> The VP Legal for Apache has determined that the JSON processing
> library
> > >>>> from json.org <https://github.com/stleary/JSON-java> is not
usable
> > as a
> > >>>> dependency by Apache projects. This is because the license includes
> a
> > >>>> line
> > >>>> that places a field of use condition on downstream users in a way
> > that is
> > >>>> not compatible with Apache's license.
> > >>>>
> > >>>> This decision is, unfortunately, a change from the previous
> situation.
> > >>>> While the current decision is correct, it would have been nice
if we
> > had
> > >>>> had this decision originally.
> > >>>>
> > >>>> As such, some existing projects may be impacted because they assumed
> > that
> > >>>> the json.org dependency was OK to use.
> > >>>>
> > >>>> Incubator projects that are currently using the json.org library
> have
> > >>>> several courses of action:
> > >>>>
> > >>>> 1) just drop it. Some projects like Storm have demos that use
> > twitter4j
> > >>>> which incorporates the problematic code. These demos aren't core
and
> > >>>> could
> > >>>> just be dropped for a time.
> > >>>>
> > >>>> 2) help dependencies move away from problem code. I have sent a
pull
> > >>>> request to twitter4 <https://github.com/yusuke/twitter4j/pull/254
> >j,
> > for
> > >>>> example, that eliminates the problem. If they accept the pull,
then
> > all
> > >>>> would be good for the projects that use twitter4j (and thus
> json.org)
> > >>>>
> > >>>> 3) replace the json.org artifact with a compatible one that is
open
> > >>>> source.
> > >>>> I have created and published an artifact based on clean-room Android
> > code
> > >>>> <https://github.com/tdunning/open-json> that replicates the
most
> > >>>> important
> > >>>> parts of the json.org code. This code is compatible, but lacks
some
> > >>>> coverage. It also could lead to jar hell if used unjudiciously
> > because it
> > >>>> uses the org.json package. Shading and exclusion in a pom might
> help.
> > Or
> > >>>> not. Go with caution here.
> > >>>>
> > >>>> 4) switch to safer alternatives such as Jackson. This requires
code
> > >>>> changes, but is probably a good thing to do. This option is the
one
> > that
> > >>>> is
> > >>>> best in the long-term but is also the most expensive.
> > >>>>
> > >>>>
> > >>>> ---------- Forwarded message ----------
> > >>>> From: Jim Jagielski <jim@apache.org>
> > >>>> Date: Wed, Nov 23, 2016 at 6:10 AM
> > >>>> Subject: JSON License and Apache Projects
> > >>>> To: ASF Board <board@apache.org>
> > >>>>
> > >>>>
> > >>>> (forwarded from legal-discuss@)
> > >>>>
> > >>>> As some of you may know, recently the JSON License has been
> > >>>> moved to Category X (https://www.apache.org/legal/
> resolved#category-x
> > ).
> > >>>>
> > >>>> I understand that this has impacted some projects, especially
> > >>>> those in the midst of doing a release. I also understand that
> > >>>> up until now, really, there has been no real "outcry" over our
> > >>>> usage of it, especially from end-users and other consumers of
> > >>>> our projects which use it.
> > >>>>
> > >>>> As compelling as that is, the fact is that the JSON license
> > >>>> itself is not OSI approved and is therefore not, by definition,
> > >>>> an "Open Source license" and, as such, cannot be considered as
> > >>>> one which is acceptable as related to categories.
> > >>>>
> > >>>> Therefore, w/ my VP Legal hat on, I am making the following
> > >>>> statements:
> > >>>>
> > >>>>  o No new project, sub-project or codebase, which has not
> > >>>>    used JSON licensed jars (or similar), are allowed to use
> > >>>>    them. In other words, if you haven't been using them, you
> > >>>>    aren't allowed to start. It is Cat-X.
> > >>>>
> > >>>>  o If you have been using it, and have done so in a *release*,
> > >>>>    AND there has been NO pushback from your community/eco-system,
> > >>>>    you have a temporary exclusion from the Cat-X classification
thru
> > >>>>    April 30, 2017. At that point in time, ANY and ALL usage
> > >>>>    of these JSON licensed artifacts are DISALLOWED. You must
> > >>>>    either find a suitably licensed replacement, or do without.
> > >>>>    There will be NO exceptions.
> > >>>>
> > >>>>  o Any situation not covered by the above is an implicit
> > >>>>    DISALLOWAL of usage.
> > >>>>
> > >>>> Also please note that in the 2nd situation (where a temporary
> > >>>> exclusion has been granted), you MUST ensure that NOTICE explicitly
> > >>>> notifies the end-user that a JSON licensed artifact exists. They
> > >>>> may not be aware of it up to now, and that MUST be addressed.
> > >>>>
> > >>>> If there are any questions, please ask on the legal-discuss@a.o
> > >>>> list.
> > >>>>
> > >>>> --
> > >>>> Jim Jagielski
> > >>>> VP Legal Affairs
> > >>>>
> > >>>>
> > >>>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > >> For additional commands, e-mail: general-help@incubator.apache.org
> > >>
> > >>
> >
> >
> >
> > --
> > Hendrik Saly (salyh, hendrikdev22)
> > @hendrikdev22
> > PGP: 0x22D7F6EC
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message