search for: licenseing

https://bugs.freedesktop.org/show_bug.cgi?id=107874 Bug ID: 107874 Summary: Incorrect SPDX-License-Identifier on various nouveau drm kernel source files? Product: xorg Version: unspecified Hardware: Other OS: NetBSD Status: NEW Severity: normal Priority: medium

Hi Rafael, We’ve discussed why a license change is preferable over the span of several years now. I’m happy to explain over the phone, contact me off list and we can talk. -Chris > On Aug 10, 2017, at 8:33 AM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > Hi, > > I still don't see any justification in the text why a license change is >

Hi all, Now that we’ve settled on the license legalese to get to, we need to start the process of relicensing. We’re still sorting through all of the details of what this will take, but the first step is clear: new contributions to LLVM will need to be under both the old license structure and the new one (until the old structure is completely phased out). From a mechanical perspective, this is

This has already been discussed extensively in the public. The threads are available in the archives. -Chris > On Aug 10, 2017, at 1:05 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > Sorry, but I really don't think a private conversation is appropriate > for such discussions. > > If the motive cannot be explained in public I have no choice

Adjust almost all the license headers to point to the GNU website instead of the FSF postal address. 3rd party code copies are unchanged. Spotted by Rpmlint. --- v1 is: https://www.redhat.com/archives/libguestfs/2019-September/msg00079.html Makefile.am | 3 +-- autogen.sh | 3 +-- bash/Makefile.am | 3 +--

Hi all, R-exts currently requests that package authors don't include copies of standard licenses: > Whereas you should feel free to include a license file in your source distribution, please do > not arrange to install yet another copy of the GNU COPYING or COPYING.LIB files but > refer to the copies on https://www.R-project.org/Licenses/ and included in the R distribution > (in

> On Aug 10, 2017, at 2:59 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > I can find old threads about it, but nothing saying why it was decided > that contributor agreement wouldn't work. Care to send the URL? Here are some quick points that come to mind: 1. It raises the bar to contribution, because something must be “signed” before a

---------- Forwarded message ---------- From: *Sublime HQ Pty Ltd* <sales at sublimetext.com> Date: Wednesday, July 25, 2012 Subject: Sublime Text License Key To: "opticalphoenix at gmail.com" <opticalphoenix at gmail.com> Hello, Thanks for purchasing a copy of Sublime Text! Your license key is: ----- BEGIN LICENSE ----- Dennis Wright Jr Single User License EA7E-819939

Unfortunately, our lawyers say that they can't give legal advice in this context. My question would be, what are people looking for that the MIT or 2-clause BSD license don't provide? They're short, clear, widely accepted and very permissive. Another possibility might be to dual-license packages with both an OSI-approved license and whatever-else-you-like, e.g. 'MIT |

Hello! There is a problem with the current name of the "Xiph license". All the variantions of this name out there imply at least one of these two false assumptions: * that the Xiph license would be a custom license not related to the BSD license at all * that the Xiph license would be based on BSD but is not the same Both is wrong and both hurts Xiph. The license text is

In prepping our next release, we noticed that the LICENSE.TXT files were still all copyrighted 2015. I've done a bit of archaeology and it looks like the files to update are: cfe/trunk/LICENSE.TXT clang-tools-extra/trunk/LICENSE.TXT compiler-rt/trunk/LICENSE.TXT libclc/trunk/LICENSE.TXT libcxx/trunk/LICENSE.TXT libcxxabi/trunk/LICENSE.TXT lld/trunk/LICENSE.TXT llvm/trunk/LICENSE.TXT

By analogy with maintainer(), I suggest extending license() to give the licensing terms of packages as well as R itself when prompted. Below is a small patch in that direction. This won't break anything and imposes no significant maintenance burden; it has the advantage of making it ever so marginally easier to know package licenses. Given the existence of license forms like GPL >=2, I

Please don't use 'Unlimited' or 'Unlimited + ...'. Google's lawyers don't recognize 'Unlimited' as being open-source, so our policy doesn't allow us to use such packages due to lack of an acceptable license. To our lawyers, 'Unlimited + file LICENSE' means something very different than it presumably means to Uwe. Thanks, Karl On Sat, Jan 14,

R: This stems from my curiosity about the previous thread about a request for glm.nb code. The issue of package licenses was brought up and I was hoping for some clarification on that. Using the function license() or licence() gives info on the license for R, but something like license(MASS) does not give info on the license for the MASS package (perhaps it might be good to expand the

On Sat, Jan 14, 2017 at 5:49 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 13/01/2017 3:21 PM, Charles Geyer wrote: >> >> I would like the unlicense (http://unlicense.org/) added to R >> licenses. Does anyone else think that worthwhile? >> > > That's a question for you to answer, not to ask. Who besides you thinks > that it's a

My company recently started using a R library from RCRAN that is licensed under the LGPL Version 2 or greater per the DESCRIPTION file, but contains no copy of the LGPL notice, or any copyright notice. I've grown accustomed to paying attention to copyright and licensing as a Debian package maintainer, and sent the author of the package an email expressing my concern. The author believed that

Hello, CentOS team and everyone who cares about CentOS, Huawei release an Euler OS, which is an distribution based on CentOS. http://developer.huawei.com/ict/en/site-euleros/euleros-introduction According to CentOS's statement, CentOS is distributed under the GPLv2 License. http://mirror.centos.org/centos/7.4.1708/os/x86_64/EULA The GPL license requires the modified version to be

The bulk SPDX addition made all these files into GPL-2.0 licensed files. However the remainder of the project is MIT-licensed, these files (primarily header files) were simply missing the boiler plate and got caught up in the global update. Fixes: b24413180f5 (License cleanup: add SPDX GPL-2.0 license identifier to files with no license) Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>

--- COPYING.GPL | 43 +++++++++++----------- doc/Makefile.am | 6 +-- doc/Makefile.lite | 6 +-- examples/c/decode/file/Makefile.am | 6 +-- examples/c/decode/file/Makefile.lite | 6 +-- examples/c/decode/file/main.c | 6 +--

Dear All, I would like to propose adding the OSL-3.0 license to the list of "standard" licenses bundled with R: Index: share/licenses/license.db =================================================================== --- share/licenses/license.db (revision 66733) +++ share/licenses/license.db (working copy) @@ -317,3 +317,12 @@ URL: