legal July 2016

legal@lists.fedoraproject.org

19 participants
7 discussions

arpy and pyelftools ok for Fedora?
by Gary Benson 29 Jul '16

29 Jul '16

Hi, I'm writing a compiler that will eventually be a build dependency of glibc and so (hopefully!) end up in Fedora. I want to use two Python libraries as dependencies, but I'd like clarification that both have ok licenses for Fedora before I dive in. 1. https://pypi.python.org/pypi/arpy This one has no LICENSE file; the top of the source file says this: # Copyright 2011 Stanisław Pitucha. All rights reserved. # Copyright 2013 Helmut Grohne. All rights reserved. # # Redistribution and use in source and binary forms, with or without modification, are # permitted provided that the following conditions are met: # # 1. Redistributions of source code must retain the above copyright notice, this list of # conditions and the following disclaimer. # # 2. Redistributions in binary form must reproduce the above copyright notice, this list # of conditions and the following disclaimer in the documentation and/or other materials # provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY Stanisław Pitucha ``AS IS'' AND ANY EXPRESS OR IMPLIED # WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND # FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL Stanisław Pitucha OR # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR # CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR # SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON # ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING # NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF # ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # # The views and conclusions contained in the software and documentation are those of the # authors and should not be interpreted as representing official policies, either expressed # or implied, of Stanisław Pitucha. Could you confirm that this is 2 clause BSD ("License: BSD") and that I just need to get the maintainers to add a LICENSE file for this to be ok for Fedora? 2. https://pypi.python.org/pypi/pyelftools This one has two license files, LICENSE: pyelftools is in the public domain (see below if you need more details). pyelftools uses the construct library for structured parsing of a binary stream. construct is packaged in pyelftools/construct - see its LICENSE file for the license. ------------------------------------------------------------------------------- This is free and unencumbered software released into the public domain. Anyone is free to copy, modify, publish, use, compile, sell, or distribute this software, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means. In jurisdictions that recognize copyright laws, the author or authors of this software dedicate any and all copyright interest in the software to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. For more information, please refer to <http://unlicense.org/> and elftools/construct/LICENSE: Copyright (C) 2009 Tomer Filiba, 2010-2011 Corbin Simpson Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Am I right that the second is MIT (Modern Style with sublicense) and that this package would have "License: Public Domain and MIT"? Thanks in advance, Gary -- http://gbenson.net/

2 2

Switching to SPDX in license tags redux
by Richard Fontana 29 Jul '16

29 Jul '16

About a year ago Haïkel Guemar started a thread[1] on devel@ and legal@ about adopting SPDX (I think he meant the entirety of the SPDX specification and not just the SPDX license identifiers). I'd like to propose reconsideration of replacement of the existing Fedora license tag scheme with the SPDX license identifiers. I've been mildly critical of SPDX on, frankly, mostly political and aesthetic grounds (to the point of asserting that the SPDX identifiers represent a form of cultural imperialism). I've complained about and lamented the apparent rising influence of the SPDX identifiers (based on the number of instances in recent years of people making non-ironic references in normal discourse to things like "Apache 2" [which I assume derives from SPDX's Apache-2.0, for what we all used to call the Apache License except for those who insist on calling it "ASL"] and "BSD-2-Clause" [for what was once rightly called the 2-clause BSD license]). Nevertheless, I am starting to think that the venerable Fedora license tag system has outlived its usefulness. The main annoyance is not the abbreviations themselves, which I find quite charming overall, but the degree to which a single abbreviation can refer to a potentially large set of what I'd think of as substantively different license texts. The SPDX identifiers are not a perfect solution since there are so many distinct license texts encountered in Fedora which are not currently the subject of an SPDX short identifier and are not likely ever to be. But I could envision a Fedora extension to the SPDX identifiers. Then again, maybe my suspicion that there could be some benefit to rebasing off the SPDX identifiers is not well informed. As an aside, I detect that in a lot of discussion of the topic of SPDX identifiers there is a sort of "standardization is always good, no matter the cost" bias at work, and for better or worse I think I am immune to that bias. In full candor, I imagine the benefits to Fedora itself of using SPDX identifiers are likely quite low, and so perhaps not worth the disruption of switching. I do see some potential benefit for Red Hat as a downstream commercial inheritor of Fedora packages. So, any thoughts on this? What's the right forum in which to raise this issue? (I'm only raising it here since Haïkel did so last year and it's the only arguably on-topic Fedora mailing list I'm already subscribed to). This is not a suggestion to adopt the SPDX specification in any broader sense. I don't really have a well-informed non-political view of it other than to observe that it seems to be mainly of interest to a narrow group of enthusiasts at present and also it seems like it would be highly impractical and pointless for Fedora to consider such a thing. Richard [1] http://www.spinics.net/linux/fedora/fedora-legal/msg02633.html

8 15

About Facebook updated open source patent grant
by Haïkel 26 Jul '16

26 Jul '16

Hi, It appears that since April, 2015, Facebook updated their open source patent grant. https://code.facebook.com/posts/1639473982937255/updating-our-open-source-p… Some companies like Google decided to ban Facebook software from their toolbox since. https://news.ycombinator.com/item?id=9271331 The actual conditions added to all Facebook projects: https://github.com/facebook/osquery/blob/master/PATENTS Potentially, it could mean that no Facebook open source projects can be shipped in Fedora including high-profile projects like React.Native. The worse being that such javascript library are often bundled without notice ... Regards; H;

3 4

"Fedora Incubator/Innovator/Experimental" branding
by Matthew Miller 21 Jul '16

21 Jul '16

I have an idea¹ for creating a label for experimental/innovative work within the Fedora Project which is not ready to be (or maybe is never intended to be) Official Fedora. For example, release engineering wants to make sure that all bits that are "official" go through releng processes — which is totally reasonable, and helps support the high quality people have come to expect from the Fedora name. At the same time, we have a charter to be leaders, and to do that we need a space where we can be more flexible. The secondary mark (Fedora Remix) can provide an avenue for this, but it's made for work done entirely outside of the Fedora project umbrella. I'd like some way to label projects which are done by Fedora developers using Fedora resources and in line with the Fedora foundations but which are not part of the traditional OS or infrastructure with all of the expectations those things bring. From a legal standpoint: a) does this make sense and b) what would we need to do make it happen? 1. http://lists.fedoraproject.org/archives/list/council-discuss@lists.fedorapr… -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

6 9

License files in debuginfo packages
by Jason L Tibbitts III 15 Jul '16

15 Jul '16

Does Fedora/Red Hat Legal have any opinion on whether debuginfo packages need to include license files? Background: There is a packaging guideline, drafted long ago according to requirements given by the legal team, regarding the placement of license files as they relate to subpackages: https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Subpackage_Lic… However, RPM itself generates debuginfo packages automatically in a way that's not really controllable by the packager. These packages do not have dependencies on the base packages and will not generally include license files. Since, like drpms and such, they are a non-packager-controlled product of the build system, the packaging committee hasn't ever considered them subject to most guidelines besides a general "turn them off if they aren't useful" rule. Personally I'd like to keep doing that, but an FPC ticket was opened (https://fedorahosted.org/fpc/ticket/639), so.... I will relay any feedback back to the packaging committee. - J<

5 6

Sleepycat license with SaaS restriction
by Florian Weimer 13 Jul '16

13 Jul '16

cryptlib is licensed under the Sleepycat license with a SaaS restriction: “Note that decoupling the software from the user, for example by running in a SaaS configuration, does not exempt you from these requirements.” (Full text attached.) This was not part of the original Sleepycat license, so a new license tag is required. Maybe this license is not even free; this additional clause seems to be a restriction on use. But perhaps it is not so different from the AGPL. Thanks, Florian

4 6

Sleepycat license compatibility and GPL version 3
by Florian Weimer 04 Jul '16

04 Jul '16

cryptlib has entered rawhide and is licensed under the Sleepycat license (among other things). Historically, the Sleepycat license was deemed compatible with the GPL, version 2, because it was another (soft) copyleft license. However, I'm not so sure if this is true for GPL, version 3. The Sleepycat license implements copyleft like this: “ 3. Redistributions in any form must be accompanied by information on how to obtain complete source code for the cryptlib software and any accompanying software that uses the cryptlib software. The source code must either be included in the distribution or be available for no more than the cost of distribution, and must be freely redistributable under reasonable conditions. For an executable file, complete source code means the source code for all modules it contains or uses. […] ” The above appears to be a further restriction on top of the GPL, version 3, which gives this permission: “ You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you. ” I think it is impossible to grant a downstream user these additional permissions if the combined work also needs to comply with the Sleepycat license. Should <https://fedoraproject.org/wiki/Licensing:Main> be updated to state that the Sleepycat license is only compatible with the GPL, version 2? Thanks, Florian

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal July 2016