Re: New License/Exception Request: BTC License (BTC)

[Josh Habdas]

Thanks to all of your for your feedback. It's very helpful for me as I
begin navigating these new waters. I will find this rooftop and I will
sing. But I cannot do it alone. And so now I rally. If you can share my
idea with others, I'm open to speaking with anyone I can about the concept
and how it might be improved for the benefit of individual FOSS developers
worldwide.

Warm regards,
Josh

On Wed, Jul 12, 2017 at 10:43 PM Brad Edmondson 
wrote:

> Hi Josh,
>
> I agree with Philippe here (SPDX looks to use "in the field" as a key
> factor in adding a license to the list), but I do in fact think your idea
> of inserting BTC or other crypto addresses in copyright and/or author
> statements is an interesting one. I hope you won't take this result as
> discouragement, but rather a win: most SPDX licenses (and not just ISC) are
> already compatible with your idea! Go forth and be merry, shout it from the
> rooftops, etc.!
>
> I will be interested to see how this goes, as I suspect a non-trivial
> number of FOSS developers like the idea of credit (somewhat similar to git
> "blame," yes?) and a simple, low-txn-cost replacement for begware that
> sometimes accompanies licenses (really, almost frictionless). I wish you
> luck!
>
> Best,
> Brad Edmondson
>
> --
> Brad Edmondson, *Esq.*
> 512-673-8782 <(512)%20673-8782> | brad.edmond...@gmail.com
>
> On Wed, Jul 12, 2017 at 6:01 AM, Josh Habdas  wrote:
>
>> Thank you for this valuable information, Philippe. I will pursue your
>> advice. Thank you all for your time.
>>
>> On Wed, Jul 12, 2017 at 5:42 PM Philippe Ombredanne 
>> wrote:
>>
>>> On Wed, Jul 12, 2017 at 10:21 AM, Josh Habdas  wrote:
>>>
>>> > For the license to receive adoption it needs to be on the SPDX License
>>> List.
>>> > I am but I small Fish in a large pond.
>>>
>>> Josh: you are getting this entirely backwards.
>>>
>>> Instead, for a license to be on the SPDX list it must have received
>>> adoption first. The purpose of the list is not to bless new licenses
>>> but to provide a shorthand for common, adopted licenses [1]:
>>>
>>> The SPDX License List is a list of commonly found licenses and
>>> exceptions
>>> used for open source and other collaborative software.
>>>
>>> The key word here is "commonly" And this is further developed on
>>> the same page.
>>> If you want a new license to be "open source"-approved, you should
>>> contact the OSI instead.
>>>
>>> > The ideal outcome is to provide a common template for a simple
>>> permissive
>>> > canonical crypto license to make it simple for users to add crypto
>>> wallet
>>> > addresses as mentioned in the Hacker Noon article.
>>> >
>>> > Ideally we can avoid license proliferation here but I need to have a
>>> new
>>> > template accepted for the copyright statement to show the proper way
>>> to use
>>> > it. Will that necessitate the creation of a unique new license text,
>>> or can
>>> > this be done creatively without causing a new license in terms?
>>>
>>> A copyright statement is a copyright statement , a license text is a
>>> license text.
>>> As much as you would like these two to be conflated in one, this is
>>> not the way things work as stated by posts in this thread.
>>>
>>> I think you have received a lot of valuable feedback and push back
>>> here on your idea.
>>>
>>> So go ahead and submit your new license idea at the OSI if you feel
>>> like it, though I consider this a terribly bad idea to submit a new
>>> text and this will unlikely help your new license to receive any
>>> adoption. Since there is really nothing novel, and you are eventually
>>> considering creating a new license text just for the purpose of having
>>> something different I doubt this would receive much consideration
>>> there too.
>>>
>>> You want to define a new way to use copyright statements creatively.
>>> So promote this but mixing this up with license texts and asking for a
>>> unique identifier does not make sense to me and to most on this list.
>>> There is not much more to say.
>>>
>>> [1] https://spdx.org/spdx-license-list/license-list-overview
>>> --
>>> Cordially
>>> Philippe Ombredanne
>>>
>>
>> ___
>> Spdx-legal mailing list
>> Spdx-legal@lists.spdx.org
>> https://lists.spdx.org/mailman/listinfo/spdx-legal
>>
>>
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New License/Exception Request: BTC License (BTC)

[Brad Edmondson]

Hi Josh,

I agree with Philippe here (SPDX looks to use "in the field" as a key
factor in adding a license to the list), but I do in fact think your idea
of inserting BTC or other crypto addresses in copyright and/or author
statements is an interesting one. I hope you won't take this result as
discouragement, but rather a win: most SPDX licenses (and not just ISC) are
already compatible with your idea! Go forth and be merry, shout it from the
rooftops, etc.!

I will be interested to see how this goes, as I suspect a non-trivial
number of FOSS developers like the idea of credit (somewhat similar to git
"blame," yes?) and a simple, low-txn-cost replacement for begware that
sometimes accompanies licenses (really, almost frictionless). I wish you
luck!

Best,
Brad Edmondson

--
Brad Edmondson, *Esq.*
512-673-8782 | brad.edmond...@gmail.com

On Wed, Jul 12, 2017 at 6:01 AM, Josh Habdas  wrote:

> Thank you for this valuable information, Philippe. I will pursue your
> advice. Thank you all for your time.
>
> On Wed, Jul 12, 2017 at 5:42 PM Philippe Ombredanne 
> wrote:
>
>> On Wed, Jul 12, 2017 at 10:21 AM, Josh Habdas  wrote:
>>
>> > For the license to receive adoption it needs to be on the SPDX License
>> List.
>> > I am but I small Fish in a large pond.
>>
>> Josh: you are getting this entirely backwards.
>>
>> Instead, for a license to be on the SPDX list it must have received
>> adoption first. The purpose of the list is not to bless new licenses
>> but to provide a shorthand for common, adopted licenses [1]:
>>
>> The SPDX License List is a list of commonly found licenses and
>> exceptions
>> used for open source and other collaborative software.
>>
>> The key word here is "commonly" And this is further developed on
>> the same page.
>> If you want a new license to be "open source"-approved, you should
>> contact the OSI instead.
>>
>> > The ideal outcome is to provide a common template for a simple
>> permissive
>> > canonical crypto license to make it simple for users to add crypto
>> wallet
>> > addresses as mentioned in the Hacker Noon article.
>> >
>> > Ideally we can avoid license proliferation here but I need to have a new
>> > template accepted for the copyright statement to show the proper way to
>> use
>> > it. Will that necessitate the creation of a unique new license text, or
>> can
>> > this be done creatively without causing a new license in terms?
>>
>> A copyright statement is a copyright statement , a license text is a
>> license text.
>> As much as you would like these two to be conflated in one, this is
>> not the way things work as stated by posts in this thread.
>>
>> I think you have received a lot of valuable feedback and push back
>> here on your idea.
>>
>> So go ahead and submit your new license idea at the OSI if you feel
>> like it, though I consider this a terribly bad idea to submit a new
>> text and this will unlikely help your new license to receive any
>> adoption. Since there is really nothing novel, and you are eventually
>> considering creating a new license text just for the purpose of having
>> something different I doubt this would receive much consideration
>> there too.
>>
>> You want to define a new way to use copyright statements creatively.
>> So promote this but mixing this up with license texts and asking for a
>> unique identifier does not make sense to me and to most on this list.
>> There is not much more to say.
>>
>> [1] https://spdx.org/spdx-license-list/license-list-overview
>> --
>> Cordially
>> Philippe Ombredanne
>>
>
> ___
> Spdx-legal mailing list
> Spdx-legal@lists.spdx.org
> https://lists.spdx.org/mailman/listinfo/spdx-legal
>
>
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New License/Exception Request: BTC License (BTC)

[Josh Habdas]

Thank you for this valuable information, Philippe. I will pursue your
advice. Thank you all for your time.
On Wed, Jul 12, 2017 at 5:42 PM Philippe Ombredanne 
wrote:

> On Wed, Jul 12, 2017 at 10:21 AM, Josh Habdas  wrote:
>
> > For the license to receive adoption it needs to be on the SPDX License
> List.
> > I am but I small Fish in a large pond.
>
> Josh: you are getting this entirely backwards.
>
> Instead, for a license to be on the SPDX list it must have received
> adoption first. The purpose of the list is not to bless new licenses
> but to provide a shorthand for common, adopted licenses [1]:
>
> The SPDX License List is a list of commonly found licenses and
> exceptions
> used for open source and other collaborative software.
>
> The key word here is "commonly" And this is further developed on
> the same page.
> If you want a new license to be "open source"-approved, you should
> contact the OSI instead.
>
> > The ideal outcome is to provide a common template for a simple permissive
> > canonical crypto license to make it simple for users to add crypto wallet
> > addresses as mentioned in the Hacker Noon article.
> >
> > Ideally we can avoid license proliferation here but I need to have a new
> > template accepted for the copyright statement to show the proper way to
> use
> > it. Will that necessitate the creation of a unique new license text, or
> can
> > this be done creatively without causing a new license in terms?
>
> A copyright statement is a copyright statement , a license text is a
> license text.
> As much as you would like these two to be conflated in one, this is
> not the way things work as stated by posts in this thread.
>
> I think you have received a lot of valuable feedback and push back
> here on your idea.
>
> So go ahead and submit your new license idea at the OSI if you feel
> like it, though I consider this a terribly bad idea to submit a new
> text and this will unlikely help your new license to receive any
> adoption. Since there is really nothing novel, and you are eventually
> considering creating a new license text just for the purpose of having
> something different I doubt this would receive much consideration
> there too.
>
> You want to define a new way to use copyright statements creatively.
> So promote this but mixing this up with license texts and asking for a
> unique identifier does not make sense to me and to most on this list.
> There is not much more to say.
>
> [1] https://spdx.org/spdx-license-list/license-list-overview
> --
> Cordially
> Philippe Ombredanne
>
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

RE: revised wording for top of exceptions page

[Zavras, Alexios]

My engineering, non-legal view is that a license specifies:

  *   What you are allowed to do (permissions); and
  *   What you must do (obligations).
[excuse the non-legal naming]

I assume that a “modification” may add to or remove from both categories.
Is this what we want the texts to be used via WITH to cover?
All the four variants? Or a subset of these (like “only additional permissions” 
or “only removal of obligations”)?

-- zvr –

From: spdx-legal-boun...@lists.spdx.org 
[mailto:spdx-legal-boun...@lists.spdx.org] On Behalf Of Michael Dolan
Sent: Tuesday, 11 July, 2017 00:12
To: Richard Fontana 
Cc: SPDX-legal 
Subject: Re: revised wording for top of exceptions page


On Mon, Jul 10, 2017 at 3:32 PM, Richard Fontana 
> wrote:
There was one notorious case of the use of GPLv2 with a permissive and 
restrictive additional term that was described at the time as an "exception" -- 
Red Hat's license for Liberation Fonts 1.0. See: 
https://en.wikipedia.org/wiki/Liberation_fonts#Distribution

I wouldn't particularly recommend use of a 'WITH' expression to describe 
Liberation Fonts 1.0, but might not be the only example of a use of "exception" 
by a licensor (and the general public too) in this sense in the real world. 
IOW, there could be multiple cases in the real world of things called 
"exceptions" that are not "additional permissions".

Richard

That's a similar concern I raised on the call last week - though at the time I 
admittedly lacked a real world example as you have provided here. I was 
considering mentioning the "FreeRTOS GPL exception" 
(http://www.freertos.org/license.txt) which I discovered recently.  (I do not 
endorse what they created as an "exception", in fact they also refer to it as a 
"modification to the GPL", - I'm just citing its existence.)

Regardless of the example, the phrase I keep coming back to for describing 
exceptions is "modifier of something". I think of these as modifiers that only 
exist when applied to a license. Admittedly some licenses (though not all), 
prevent explicit "modification" of the license, but they all modify terms of 
what you can or cannot do or the conditions that apply.

The language I've used below may need cleanup, but the high level construct I 
was thinking about was similar to the following statement. Plain text is not 
easy for redlining, so I've used [ADD: ] and [REMOVE: ] in brackets to show 
additions and deletions from the original proposal Jilayne and Bradley took the 
initiative to draft (thank you).

The SPDX License List includes a list of commonly found exceptions to open 
source licenses.  Exceptions [ADD: may exempt, modify or add terms, permissions 
or conditions] [REMOVE: grant additional permissions] beyond those [REMOVE: 
already given] in the license that the exception modifies.  These exceptions 
are not stand-alone licenses; rather, they are designed for use with the 
License Expression Syntax operator, "WITH", to identify a license that includes 
an [REMOVE: additional permission] [ADD: Exception] [REMOVE: beyond those in 
the main license].

A "clean version" would read as:

The SPDX License List includes a list of commonly found exceptions to open 
source licenses.  Exceptions may exempt, modify or add terms, permissions or 
conditions beyond those in the license that the exception modifies.  These 
exceptions are not stand-alone licenses; rather, they are designed for use with 
the License Expression Syntax operator, "WITH", to identify a license that 
includes an exception.

-- Mike
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal

Re: New License/Exception Request: BTC License (BTC)

[Josh Habdas]

Hi Jilayne,

For the license to receive adoption it needs to be on the SPDX License
List. I am but I small Fish in a large pond.

The ideal outcome is to provide a common template for a simple permissive
canonical crypto license to make it simple for users to add crypto wallet
addresses as mentioned in the Hacker Noon article.

Ideally we can avoid license proliferation here but I need to have a new
template accepted for the copyright statement to show the proper way to use
it. Will that necessitate the creation of a unique new license text, or can
this be done creatively without causing a new license in terms?

Regards,
Josh
On Wed, Jul 12, 2017 at 6:32 AM J Lovejoy  wrote:

> Hi Josh,
>
> As this is the exact same license text as ISC, save for the copyright line
> which is not counted as for purposes of matching license texts as per the
> SPDX License List Matching Guidelines, there is no need to add this to the
> SPDX License List, as the license would be identified as or matched to ISC.
> Thus, if one wanted to use an SPDX short identifier to refer to this
> license, they would use the short identifier ISC license (which is “ISC”).
> The copyright line can be different, the license is still the same.
>
> I’m not sure if you are familiar with the larger SPDX project, but the
> SPDX specification serves the goal to create a standard way to identify the
> license, copyright, provenance, and other such information in a software
> ‘bill of materials’. This effort was born out of the reality that companies
> along the supply chain ask for and exchange this information and by having
> a standard way to report this data, redundant work can be reduced.  When
> the SPDX specification first was getting started, we recognized the need
> for a reliable and concise way to refer to common licenses in an SPDX
> document (instead of having to repeat the license over and over). This, in
> turn would also help prevent those people processing such information from
> having to read the same license over and over.  And so, the SPDX License
> List was born.
>
> Of course, there is a need for a reliable and concise way to refer to
> common licenses in many other instances besides an SPDX document and so the
> SPDX License List has seen adoption in a host of other ways.  Notably,
> developers are using the short identifiers as a concise, reliable, and
> machine-readable way to identify the license on a per-file basis (for
> example:
> https://github.com/ARM-software/arm-trusted-firmware/blob/master/lib/aarch32/cache_helpers.S
>  ).
> This ensures the license goes with the file (even if the license file
> doesn’t follow the rest of the code files) which is immensely helpful for
> licensers and downstream recipients. Whether you use the standard license
> header as is recommended by the license (if there is one) or the SPDX
> identifier or the entire license text for shorter licenses - identifying
> the license in every file is recommended practice by the FSF*, Apache
> Foundation, Eclipse Foundation, etc. Anyway, I mention this because your
> articles cites the distraction of long license headers as well as your
> unfortunate experience of someone copying your code without retaining your
> copyright notice and the license (I’m sorry to hear about this and yes, I
> think you should say something to this person - a gentle reminder may often
> be enough to correct the error!).
>
> I’m not sure what else to tell you here. I don’t think any license really
> prevents you from replacing your name in the copyright notice with a
> bitcoin address.  I’m also not sure this change, which is not a change to
> the license, will make FOSS licensing sexy, but then again, nothing may
> achieve that goal! ;)
>
> Finally and on a slightly separate note - your assertion that there are
> some "20 odd licenses now awaiting review” by the SPDX Legal team is
> incorrect.
>
>
> Thanks,
> Jilayne
>
> SPDX Legal Team co-lead
> opensou...@jilayne.com
>
>
> On Jul 5, 2017, at 7:04 PM, Josh Habdas  wrote:
>
> I can change something insignificant if it helps, but this seemed better
> On Thu, Jul 6, 2017 at 2:03 AM Josh Habdas  wrote:
>
>> It's the exact same, in fact. Save for the copyright line. And here's why
>> this new license is important:
>>
>>
>> https://medium.com/@jhabdas/introducing-the-btc-license-28650887eb11?source=linkShare-d4a43ea991d3-1499277791
>> On Thu, Jul 6, 2017 at 1:57 AM Richard Fontana 
>> wrote:
>>
>>> This seems to be equivalent to the ISC license from an SPDX point of
>>> view (see https://spdx.org/spdx-license-list/matching-guidelines:
>>> " Ignore copyright notices. A copyright notice consists of the following
>>> elements, for example: "2012 Copyright, John Doe. All rights reserved." or
>>> "(c) 2012 John Doe." Templates may or may not include markup for this
>>> guideline.")
>>>
>>>
>>> --
>>>
>>> From: "Josh Habdas"