On Tue, 2008-12-09 at 23:03 +0100, Matthias Saou wrote:
> > >>>>> "TC" == Tom \"spot\" Callaway <Tom> writes:
> > TC> Given that it does not give permission for us to redistribute (the
> > TC> cornerstone requirement for Content licenses), this license is not
> > TC> acceptable for Fedora.
> > I guess I'm glad I looked before approving the package, but I have to
> > wonder: Do the cacert folks actually want anyone to use their
> > certificates? I mean, this prevents basically everyone from using
> > them, because they can't come with the OS or the browser.
> Personally, the more I read the document, the more I'm confused.
> "You may NOT distribute certificates or root keys under this
> licence"... does this mean we can distribute under a different license?
Well, sortof. The wording here is strange because you can get a
different license from the CA issuer. We can't just pick a license, but
the CA issuer might be willing to give us a different one.
> Would it be worth getting in contact with CAcert.org in order to try
> and have them allow us to redistribute the root certs under conditions
> which are acceptable to the Fedora Project?
Probably, yes. :)
I have been surprised that - despite their prominence - projects like
VirtualBox and Chrome (the open source version, built directly from
Chromium) have not been packaged for Fedora. I might be interested in doing
this, and just wanted to know if there are any legal hurdles to it being
done, in case that is the reason it has not been done yet?
its been more than a year since FreeCAD was rejected on the basis of a
non-compliant license on one of its components, particularly
OpenCascade. (see review for bug #459125 ->
https://bugzilla.redhat.com/show_bug.cgi?id=459125). That review
concluded with version 6.3 of the OpenCascade license. The license has
seen two modifications since then and is now at 6.5 (see
Is this license now acceptable?
In consultation with Red Hat Legal and the Fedora Board, I have
implemented a chance to Fedora's policy regarding software marked as
being in the Public Domain. The new policy is as follows:
Works which are clearly marked as being in the Public Domain, and for
which no evidence is known to contradict this statement, are treated in
Fedora as being in the Public Domain, on the grounds that the intentions
of the original creator are reflected by such a use, even if due to
regional issues, it may not have been possible for the original creator
to fully abandon all of their their copyrights on the work and place it
fully into the Public Domain. If you believe that a work in Fedora which
is marked as being in the Public Domain is actually available under a
copyright license, please inform us of this fact with details, and we
will immediately investigate the claim.
The wiki home for this new policy is here:
This policy is effective immediately. If you have had a package rejected
by Fedora because it was in the Public Domain and we were unable to
determine the validity of the Public Domain declaration, the declaration
was deemed to be incomplete, or there were jurisdictional issues with
the declaration, please feel free to open new package reviews or contact
legal(a)fedoraproject.org to lift any FE-Legal blocks.
If you have questions about this change in policy, feel free to email me
directly or send a mail to the Fedora Legal mailing list
<legal(a)lists.fedoraproject.org> (note: it is moderated and gets a metric
ton of spam, so I probably won't see it if you're not subscribed).
I'm trying package perl-Wx-Scintilla, which has lot of problems. But at
the moment I'd like to solve license. The main package is licensed "same
as Perl". Two files are under wxWindows, which is the same as wxWidgets
license. But there is also directory under some kind of MIT.
License for Scintilla and SciTE
Copyright 1998-2003 by Neil Hodgson <neilh(a)scintilla.org>
All Rights Reserved
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
NEIL HODGSON DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS
SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS, IN NO EVENT SHALL NEIL HODGSON BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE
OR PERFORMANCE OF THIS SOFTWARE.
Could you clarify it this is MIT and if I can mark it as package under
"(GPL+ or Artistic) and wxWidgets and MIT" ?
BaseOS team Brno
In other words, say there are a small number of source files in a packaged
(tarball) work that lack any or clear copyright header, should that be
considered a review blocker?
IANAL and being a generally pragmatic fellow, I'd hoped that we could
generally give upstreams the benefit of the doubt, for lack of any contrary
Fwiw, yes, I have a concrete case in mind here,
and yes, I've asked upstream for clarification (without reply so far). I'd
also hoped not to have a pkg review blocked semi-indefinitely on something
like this though.
What say you?
I am preparing Ruby 1.9.3 for Fedora 17 and I came to interesting
license question. Ruby was always double licensed, i.e. Ruby and GPLv2.
However, Ruby 1.9.3 is going to be licensed under Ruby and BSD license.
The interesting part is, that there is certain amount of gems, which are
"distributed under the same conditions as ruby". For example
rubygem-POpen4, rubygem-thin, rubygem-cairo.
Does that apply that the gems are going to be licensed with the same
version of Ruby in distribution? Or if they distribute the LICENSE file
of Ruby 1.8.7, where is specified that the license is same as Ruby,
which means GPLv2 or Ruby is this enough? Is it necessary to clarify the
license with every upstream due to this change?