public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: "Doran\, Mark" <mark.doran@intel.com>
Cc: edk2-devel@lists.01.org
Subject: Re: [RFC] Change EDK II to an Apache 2.0 License
Date: Fri, 7 Dec 2018 22:44:57 +0100 (CET)	[thread overview]
Message-ID: <9e5cd1cd082af945@bloch.sibelius.xs4all.nl> (raw)
In-Reply-To: <DFF7383D242A84439AD17BCBA41787FE9C6D9968@ORSMSX109.amr.corp.intel.com> (mark.doran@intel.com)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8966 bytes --]

> From: "Doran, Mark" <mark.doran@intel.com>
> Date: Fri, 7 Dec 2018 17:44:15 +0000
>
> Hi Mark:
> 
> Thanks for your note.  The terms and conditions for EDK II code include two
> elements today and they have to be considered together.  Namely the
> Contributor Agreement and the two clause BSD outbound terms.  Together those
> terms sum to a direct equivalent of the terms contained in the Apache 2.0.
> As such the advice we have received confirms that in practical terms
> changing the existing Contributor Agreement and code license tuple to the
> singular Apache 2.0 should not make any material difference to contributors
> or consumers of the EDK II code.  In other words, if you are already
> supporting platforms that include code under the existing T's & C's then the
> proposed change should not be an impediment to continuing that or supporting
> future platforms based on EDK II code.

But the contributor agreement only applies for people that want to
contribute their code back to the EDK II codebase.  For end-users of
the code, or people that want to simply distribute the code or
binaries, Apacche 2.0 adds several additional restrictions over two
clause BSD.

> I recognize that changing something like this is somewhat unusual, but there
> are precedents (OpenSSL for example).  On balance we believe the benefits of
> switching to an OSI-approved license formulation and removing the need for
> future contributors to sign up to a Contributor Agreement outweigh the
> effort the project will make to effect the change.  Both of those results
> should make it easier for people to jump in and work on the code -- and
> that's what we are after here: taking away potential barriers to
> participation.

Funny you mention OpenSSL.  That was a pretty controversial move.
Several code authors did not agree with the license change and they
had to rewrite some of the codebase to replace that code.  Their
original plan was also to simply change the license on code from
authors that they couldn't track down.  Not sure if they followed
through on that, but if they did, that's totally unacceptable.

Since the license change, code from OpenSSL can no longer be
integrated into OpenBSD.  And as a consequence software like OpenSSH
is slowly moving from away from using OpenSSL code, integrating
BSD-licensed implementations of the necessary algorithms instead.

To be honest these precedennts are an important reason why I wanted to
point out that Apache 2.0 is not universally accepted as a
non-restrictive license.

> I don't suppose we could ever pick one license that would please absolutely
> everyone for something like this -- it will always be a compromise, I know.
> I think in this case feedback we have had from various project participants
> including those from commercial ventures and open source community inform
> the choice.  The qualitative summary of that comes down to providing terms
> with the least amount of strings as possible while also giving patent
> protections for users of the code.  When we first started TianoCore there
> really wasn't a suitable license that did both those things and that's how
> we ended up with the two-element terms we have today.  As I think I said
> elsewhere, had Apache 2.0 existed at the time, that's probably what we would
> have picked in the first place.
> 
> Fundamentally though we believe the proposed terms are no more restrictive
> than what already applies so if that was your concern, that the intent was
> to make the environment more restrictive, that is definitely not the case.

Thanks for taking the time to write this reply.  I appreciate it.  And
I really don't want this to turn into another lengthy discussion about
the pros and cons of different licenses.  Our time is better spent on
writing good software.

> --
> Cheers,
>
> Mark.

Thanks,

Mark.

> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> > Mark Kettenis
> > Sent: Friday, December 7, 2018 2:52 AM
> > To: Kinney, Michael D <michael.d.kinney@intel.com>
> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; edk2-
> > devel@lists.01.org
> > Subject: Re: [edk2] [RFC] Change EDK II to an Apache 2.0 License
> > 
> > > From: "Kinney, Michael D" <michael.d.kinney@intel.com>
> > > Date: Thu, 29 Nov 2018 18:39:28 +0000
> > 
> > As an OpenBSD developer I feel I have to point out that the OpenBSD
> > project considers Apache 2.0 to be a *restrictive* license.
> > 
> >   http://www.openbsd.org/policy.html
> > 
> > We (currently) don't include EDK II code in the OpenBSD OS itself, but
> > do support ARM boards that boot using EDK II-based firmware that has
> > to be included on the same boot media as the OS.  So to license change
> > would restrict us (the OpenBSD prject) and potentially others from
> > distributing working boot media for such boards under a "no strings
> > attached" license.
> > 
> > Personally, I also think clause 4b of the Apache 2.0 license is too
> > problematic for truly open source software.  Adding the required
> > notice for every change that is made is obviously unworkable as I've
> > never seen such notices in modified Apache 2.0 codebases...
> > 
> > All-in-all, from my point of view replacing a simple, easy to
> > understand, permissive license with a more complicated legal document
> > that imposes additional restrictions would be a step backwards.  No
> > doubt Intel's lawyers have a different opinion.
> > 
> > Cheers,
> > 
> > Mark Kettenis
> > 
> > > Hello,
> > >
> > > This RFC follows up on the proposal from Mark Doran to change the\x04‚

> > EDK
> > > II Project to an Apache 2.0 License.
> > >
> > >     https://lists.01.org/pipermail/edk2-devel/2018-
> > October/030385.html
> > >
> > >
> > >   ** Please provide feedback on the proposal by Friday 12/7/18. **
> > >
> > > I will be following up with pointers to public GitHub branches that
> > > contain the initial set of changes in steps (1) and (2) below for
> > > review.
> > >
> > > The proposal is to perform this change to edk2/master in the steps
> > > listed below. The license change will not be applied to any of the
> > > other existing branches in the edk2 repository.
> > >
> > > 1) Change all files with a BSD 2-Clause license and only a single
> > >    copyright statement by Intel Corporation to an Apache 2.0 license
> > >    and add an SPDX-License-Identifier statement.
> > >
> > >
> > ======================================================================
> > >    SPDX-License-Identifier: Apache-2.0
> > >
> > >    Licensed under the Apache License, Version 2.0 (the "License");
> > >    you may not use this file except in compliance with the License.
> > >    You may obtain a copy of the License at
> > >
> > >        http://www.apache.org/licenses/LICENSE-2.0
> > >
> > >    Unless required by applicable law or agreed to in writing,
> > software
> > >    distributed under the License is distributed on an "AS IS" BASIS,
> > >    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > implied.
> > >    See the License for the specific language governing permissions
> > and
> > >    limitations under the License.
> > >
> > >
> > ======================================================================
> > >
> > > 2) Update Readme.md and License.txt in the root of the edk2
> > repository to
> > >    state that content is covered by a mix of BSD 2-Clause and Apache
> > 2.0
> > >    licenses.
> > >
> > > 3) Update all documentation to state that content submitted under
> > the
> > >    Apache 2.0 license no longer requires the Tianocore Contribution
> > >    Agreement which means the following line is not required in
> > commit
> > >    messages for changes to files that are covered by an Apache 2.0
> > License.
> > >
> > >        Contributed-under: TianoCore Contribution Agreement 1.1
> > >
> > > 4) Create Wiki page(s) that provide the details of the Apache 2.0
> > License
> > >    change and provide the status of the license change for each
> > package
> > >    in the edk2 repository.  Also provide a list of the additional
> > copyright
> > >    holders that need to be contacted to accept the change to an
> > Apache 2.0
> > >    License along with the status of that acceptance.
> > >
> > > 5) After all copyright holders have accepted the change to an Apache
> > 2.0
> > >    License, change the remaining files from BSD 2-Clause to Apache
> > 2.0.
> > >
> > > 6) Update Readme.md and License.txt in the edk2 repository to state
> > that
> > >    Apache 2.0 is the preferred license for the EDK II project.
> > >
> > > Best regards,
> > >
> > > Mike
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > >
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel


  parent reply	other threads:[~2018-12-07 21:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-29 18:39 [RFC] Change EDK II to an Apache 2.0 License Kinney, Michael D
2018-11-29 22:53 ` Leif Lindholm
2018-12-07 20:07   ` Matteo Carlini
2018-12-07 21:27     ` Kinney, Michael D
2018-12-07 10:51 ` Mark Kettenis
     [not found]   ` <DFF7383D242A84439AD17BCBA41787FE9C6D9968@ORSMSX109.amr.corp.intel.com>
2018-12-07 21:44     ` Mark Kettenis [this message]
2018-12-07 22:51       ` Doran, Mark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e5cd1cd082af945@bloch.sibelius.xs4all.nl \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox