Re: but in long name of WTFYW license

[J Lovejoy]

HI Daniel,

We discussed this a bit on the call today. The license text itself does not use 
the * , which is the most important part for matching purposes. 

How to display this was discussed way, way back when this was added to the 
license list (which was one of the early versions, based on memory). The 
treatment of using a * to soften a swear word is pretty common and we seemed to 
think it was a good idea at the time. I see your point and don’t disagree, but 
I also don’t find these words offensive. Some people do. It was also pointed 
out on the call, that isn some situations, you might use the * when presenting 
a list of licenses if having a swear word on your presentation was not 
appropriate for the given audience.

Is there a reason to change this now, in your view? I”m not sure it’s worth 
changing unless there is a compelling reason or something has changed to 
warrant it. 

Thanks,
Jilayne

SPDX Legal Team co-lead
opensou...@jilayne.com


> On Apr 17, 2018, at 3:45 AM, dmg  wrote:
> 
> hi everybody,
> 
> The page of the  WTFYW license incorrectly names it as
> 
> "Do What The F*ck You Want To Public License"
> 
> https://spdx.org/licenses/WTFPL.html
> 
> the proper name of the license is, as you most likely know
> 
> "Do What The Fuck You Want To Public License"
> 
> I feel it is important for SPDX to be accurate and it should not make
> ethical decisions that affect the accuracy of the information it provides.
> 
> After all, the WTFYW is not Lord Voldemort's license :)
> it should not remain _unnamed_
> 
> -- 
> --dmg
> 
> ---
> Daniel M. German
> http://turingmachine.org
> ___
> 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: Google "Additional IP Rights Grant (Patents)"

[J Lovejoy]

Hi Kai, Philippe,

We discussed this on the legal call earlier. While this is certainly an 
additional license grant, which Google has added on top of the BSD-3-Clause, we 
decided it makes sense to add it on the “License Exceptions” list considering 
how it is used, which is not as a standalone license and otherwise, we’d have 
to create a whole new license, which no one felt was the right method.

Keep in mind we did discuss the meaning of “exceptions” and updated the 
explanatory text on the top of the page to allow for a more flexible approach 
as to what is included on the list. We might consider updating that a bit 
further in the future or even changing the name to avoid confusion, but we’ll 
save that for a rainy day.

In the meantime, does anyone know if this is used by anyone other than Google? 
If not, then it makes sense to call it “Google patent grant” or something like 
that. But if others have used it then we’ll want to  use a different title and 
add markup on the Google name.

Philippe - do you have a way to identify the precise differences in the 3 
variants you site below? (to save me from doing the low-tech Word comparison…)


Thanks,
Jilayne

SPDX Legal Team co-lead
opensou...@jilayne.com


> On May 14, 2018, at 8:00 AM, Philippe Ombredanne  wrote:
> 
> Hi Kai:
> 
> On Mon, May 14, 2018 at 2:53 PM, Kai Koehne  wrote:
>> Google uses a standard "Additional IP Rights Grant (Patents)" text in a lot 
>> of projects they've been publishing - {} sections are mine:
> [...]
>> 
>> Sources: https://webrtc.org/license/additional-ip-grant/,
>> https://www.webmproject.org/license/additional/,
>> https://github.com/ImageMagick/webp/blob/master/PATENTS,
>> https://golang.org/PATENTS
>> 
>> Does it make sense to add this to the list of Exceptions?
> 
> This makes a lot of sense to me.
> We have been tracking these (see three variants below) in ScanCode and
> DejaCode for quite a while:
> 
> - 
> https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/google-patent-license.LICENSE
> - 
> https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/google-patent-license-webm.LICENSE
> - 
> https://github.com/nexB/scancode-toolkit/blob/develop/src/licensedcode/data/licenses/google-patent-license-fuschia.LICENSE
> 
> The variants for Go and WebRTC look mostly the same.
> However I do not think of these as exceptions, but rather as plain license(s).
> 
> -- 
> Cordially
> Philippe Ombredanne
> 
> +1 650 799 0949 | pombreda...@nexb.com
> DejaCode - What's in your code?! - http://www.dejacode.com
> AboutCode - Open source for open source - https://www.aboutcode.org
> nexB Inc. - http://www.nexb.com
> ___
> 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: Notes on the license submittal tools from the SPDX legal team meeting

[J Lovejoy]

scratch that bit about attendees - Dennis has sent that info!




> On May 17, 2018, at 11:23 AM, J Lovejoy  wrote:
> 
> HI All,
> 
> I’ve posted these notes and the proposal to the meeting minutes page for May 
> 3rd here, but I don’t know who else was on the call.  Can someone fill that 
> in?
> https://wiki.spdx.org/view/Legal_Team/Minutes/2018-05-03 
> 
> 
> thanks,
> JIlayne
> SPDX Legal Team co-lead
> opensou...@jilayne.com 
> 
> 
>> On May 3, 2018, at 12:36 PM, g...@sourceauditor.com 
>>  wrote:
>> 
>> Hi Paul, Brad and Galo,
>>  
>> Below are my notes from the discussion on the SPDX GSoC project “Add New 
>> License Submittal Feature to Online Tools”.
>>  
>> We would like to have a follow-up discussion with Galo, Paul, Brad and Gary.
>>  
>> We reviewed the use cases in the proposal (attached).
>>  
>> There were three key points made during the review:
>> - The primary motivation for the tool is to make it easy for the submitters 
>> (the Producer actor)
>> - The legal team would like to continue to use github issues to track new 
>> license submittals as opposed to using the tool forms
>> - To keep the scope of the project achievable, we can take an incremental 
>> approach
>>  
>> Discussion prior to the use case reviews:
>> Do we want to require a github account for the Producers: We agreed that the 
>> Producers would not need a github account and could log in anonymously as 
>> long as an email is available
>> How do we know if the email is valid?  [I believe we decided this didn’t 
>> need to be resolved on the first release]
>> We should describe why the email is needed for the submittal – e.g. in case 
>> there are any questions, follow-up required
>>  
>> UC-001 Submit a license request:
>> We should validate the license is valid and is not a duplicate license
>> Anonymous login OK as long as email address is captured
>> As a post condition, a github issue should be submitted with the proper tags 
>> to denote a new license request. The Github API’s can be used for this 
>> purpose: https://developer.github.com/v3/issues/#create-an-issue 
>> 
>> We could add some helpful information on the different fields (e.g. what a 
>> short-identifier is, pointer to the OSI license list)
>>  
>> UC-002 View submitted license requests:
>> Since the legal team will use the github issues list to track, the view 
>> function will primarily be used by producers and people interested in the 
>> status outside of the legal team itself.  We did feel this was still a 
>> valuable use case, just with different actors.
>> No need to authenticate – could be a public access view
>> Suggest the following states for the license: submitted (non-reviewed), 
>> submitted (under-review), approved, rejected
>> The state could be determined by the tags in the issue within github
>> We discussed what we would list under approved – all licenses?  Just 
>> licenses submitted through the app?  We agreed that the list under approved 
>> would be all licenses which have been approved but not yet 
>> released/published.  Once a license is released/published it would no longer 
>> be visible.  We could add a link to the listed licenses page as a reference 
>> for all published licenses.
>>  
>> UC-003 and UC-004 Approve and Deny license request:
>> Not needed since the legal team will use github for tracking status
>>  
>> UC-005 View a license request information:
>> The actors would include the Producer and also the general public
>> Could be a drilldown from the view on UC-002
>>  
>> UC-006 Generate a license XML file
>> Actor would be the legal team since the Producer will not be required to 
>> have a github account necessary for the pull request.
>> Ideally, this could generate a pull request, but it could just download the 
>> XML and the user could create the pull request.
>> We would need to also download a test file which would be the text of the 
>> license.
>>  
>> We also discussed if the original submittal should generate the pull request 
>> with the XML file and we decided it should only generate the issue.
>>  
>> We discussed a scenario where there may be a family of licenses submitted 
>> together.  Should we support multiple licenses submitted in the same issue?
>>  
>> All: Please let me know if I missed anything.
>>  
>> Thanks,
>> Gary
>>  
>> -
>> Gary O'Neall
>> Principal Consultant
>> Source Auditor Inc.
>> Mobile: 408.805.0586
>> Email: g...@sourceauditor.com 
>>  
>> > Castillo.pdf>___
>> Spdx-legal mailing list
>> Spdx-legal@lists.spdx.org 
>> https://lists.spdx.org/mailman/listinfo/spdx-legal 
>> 

Re: Notes on the license submittal tools from the SPDX legal team meeting

[J Lovejoy]

HI All,

I’ve posted these notes and the proposal to the meeting minutes page for May 
3rd here, but I don’t know who else was on the call.  Can someone fill that in?
https://wiki.spdx.org/view/Legal_Team/Minutes/2018-05-03 


thanks,
JIlayne
SPDX Legal Team co-lead
opensou...@jilayne.com


> On May 3, 2018, at 12:36 PM, g...@sourceauditor.com wrote:
> 
> Hi Paul, Brad and Galo,
>  
> Below are my notes from the discussion on the SPDX GSoC project “Add New 
> License Submittal Feature to Online Tools”.
>  
> We would like to have a follow-up discussion with Galo, Paul, Brad and Gary.
>  
> We reviewed the use cases in the proposal (attached).
>  
> There were three key points made during the review:
> - The primary motivation for the tool is to make it easy for the submitters 
> (the Producer actor)
> - The legal team would like to continue to use github issues to track new 
> license submittals as opposed to using the tool forms
> - To keep the scope of the project achievable, we can take an incremental 
> approach
>  
> Discussion prior to the use case reviews:
> Do we want to require a github account for the Producers: We agreed that the 
> Producers would not need a github account and could log in anonymously as 
> long as an email is available
> How do we know if the email is valid?  [I believe we decided this didn’t need 
> to be resolved on the first release]
> We should describe why the email is needed for the submittal – e.g. in case 
> there are any questions, follow-up required
>  
> UC-001 Submit a license request:
> We should validate the license is valid and is not a duplicate license
> Anonymous login OK as long as email address is captured
> As a post condition, a github issue should be submitted with the proper tags 
> to denote a new license request. The Github API’s can be used for this 
> purpose: https://developer.github.com/v3/issues/#create-an-issue 
> 
> We could add some helpful information on the different fields (e.g. what a 
> short-identifier is, pointer to the OSI license list)
>  
> UC-002 View submitted license requests:
> Since the legal team will use the github issues list to track, the view 
> function will primarily be used by producers and people interested in the 
> status outside of the legal team itself.  We did feel this was still a 
> valuable use case, just with different actors.
> No need to authenticate – could be a public access view
> Suggest the following states for the license: submitted (non-reviewed), 
> submitted (under-review), approved, rejected
> The state could be determined by the tags in the issue within github
> We discussed what we would list under approved – all licenses?  Just licenses 
> submitted through the app?  We agreed that the list under approved would be 
> all licenses which have been approved but not yet released/published.  Once a 
> license is released/published it would no longer be visible.  We could add a 
> link to the listed licenses page as a reference for all published licenses.
>  
> UC-003 and UC-004 Approve and Deny license request:
> Not needed since the legal team will use github for tracking status
>  
> UC-005 View a license request information:
> The actors would include the Producer and also the general public
> Could be a drilldown from the view on UC-002
>  
> UC-006 Generate a license XML file
> Actor would be the legal team since the Producer will not be required to have 
> a github account necessary for the pull request.
> Ideally, this could generate a pull request, but it could just download the 
> XML and the user could create the pull request.
> We would need to also download a test file which would be the text of the 
> license.
>  
> We also discussed if the original submittal should generate the pull request 
> with the XML file and we decided it should only generate the issue.
>  
> We discussed a scenario where there may be a family of licenses submitted 
> together.  Should we support multiple licenses submitted in the same issue?
>  
> All: Please let me know if I missed anything.
>  
> Thanks,
> Gary
>  
> -
> Gary O'Neall
> Principal Consultant
> Source Auditor Inc.
> Mobile: 408.805.0586
> Email: g...@sourceauditor.com 
>  
>  Castillo.pdf>___
> 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: FreeRTOS exception

[Dennis Clark]

Hello Till,

Thanks very much for pointing out the updates to FreeRTOS licensing. You
can follow the progress of this request at:

https://github.com/spdx/license-list-XML/issues/645

Regards,
Dennis Clark


On Wed, May 16, 2018 at 12:44 AM, Till Jaeger via Spdx-legal <
spdx-legal@lists.spdx.org> wrote:

> Hello,
>
> https://spdx.org/licenses/freertos-exception-2.0.html refers to
> http://www.freertos.org/a00114.html#exception This page refers to the MIT
> instead of the FreeRTOS exception.
>
> The reason is:
>
> https://aws.amazon.com/blogs/opensource/announcing-freertos-kernel-v10/
>
> You might correct the link or indicate that the exception is outdated.
>
> Best,
>
> Till
>
> ___
> 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

Legal call shortly!

[Jilayne Lovejoy]

Sorry for the late reminder!

 

As for agenda:
Update on GSoC project related to legal team work (as applicable)
Go through issues tagged with “needs legal discussion”
 

Usual dialin:

Web conference: http://uberconference.com/SPDXTeam

 Optional dial in number: 415-881-1586

 No PIN needed

 

Talk soon!

Jilayne

___
Spdx-legal mailing list
Spdx-legal@lists.spdx.org
https://lists.spdx.org/mailman/listinfo/spdx-legal