Re: [Fedora-legal-list] CAcert.org license
by Tom Callaway
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. :)
~spot
7 years, 1 month
Product logos in Boxes
by Zeeshan Ali
Hi,
As you may or may not know, we have been working on a new GNOME
application, Boxes[1] that (among other things) enables users to easily
manage virtuat-machines. This also includes ability to detect
operating-systems given an installation media and presenting an
intuitive and impressive UI to user to easily install different
operating systems with minimum or no interaction. Boxes makes use of a
new library, libosinfo[2] that provides information about operating
systems (which it internally keeps in an XML database).
The reason I'm writing to you is that we really want (more like need) to
show logos of different operating systems to the user[3]. In attempt to
avoid violating possible trademark issues, here is the approach I took
in my (currently unaccepted) patches:
1. libosinfo only provides (HTTP) URLs to logos of particular OS/product
but not the logo itself in any form.
2. Boxes downloads the logo at runtime when needed (when user inserts
installation media of the OS in question or has installer ISO image in
her/his home directory), caches it on disk and presents it to the user
as shown in the screenshot[3].
So I would very much appreciate it if you can provide answers to the
following questions:
1. Is Boxes (or libosinfo) in this case is violating any trademarks
already (assuming only the logos shown in the screenshot)?
2. If the answer to the question#1 is 'no', is there a good chance we
violate trademarks of OS products in future? If so, is that avoidable?
3. If the answer to the question#1 is 'yes', could you please advice us
how to implement this essential feature without violating any
trademarks?
-- Regards,
Zeeshan Ali
[1] http://fedoraproject.org/wiki/Features/Gnome3.4
[2] https://fedorahosted.org/libosinfo/
[3] http://static.fi/~zeenix/tmp/boxes+win-fedora-ubuntu-iso-logos.png
11 years
How to specify license? CCDL or GPLv2 or ASL 2.0?
by juan.hernandez＠redhat.com
Hello,
I came accross the attached header in the source files for a package I
am working on. What is the correct license tag for that? I guess that it
should be "CDDL or GPLv2 or ASL 2.0". Is that correct?
Thanks in advance,
Juan Hernandez
11 years
Licensing Tool (diploma thesis)
by Tomas Radej
Hello,
I would like to ask for your consent with me making a particular license-checking program as a thesis assignment. This program would be about to be deployed in production, mostly in Fedora package reviewing, or for the use of individual developers outside Fedora. The problem is that the information obtained by usage of the program or disclosing obtained data could be harmful towards Fedora. Please read on for details.
The assignment is to invent a tool that:
- searches a software project (for the purpose of the thesis, only a Java software project, but more language-specific modules are intended in the future)
- determines the project's license (the means of doing that, beyond checking the license header, are to be invented)
- reports any problems or license incompatibilities found (mostly as warnings, I expect most of the checks to be based on heuristics)
- stores data in a publicly available database to speed up the process and share information, taking into consideration different builds of packages, different versions etc.
The assignment also requires devising a way to manage the database, user contributions, credibility of such etc.
It is to be noted that even though checking the compliance with Fedora licensing is a duty of every reviewer, my experience shows that it is beyond a standard package reviewer to see problems such as copy/pasted code, several classes taken from a different project with a different license (when a header is missing) etc. The aim of this program would be to help mainly with these problems as they often go unnoticed even now.
The problem is that for a successful defense of the thesis, it would be necessary (admittedly not vital) to publish the source code of the program and probably the database properties as well. I am aware that disclosing the data accumulated while checking projects in Fedora could have potentially devastating consequences, therefore I would only publish the source code of the program and bindings to a database system, which a user would need to run separately from Fedora, thus not revealing the internal data to the public. My thesis advisor deemed this idea to be satisfactory for the academia.
What I would like to ask you is if you too consider the execution of this project to be safe enough to be done and not threaten Fedora, e. g. by pointing out unnoticed licensing issues to a malefactor.
Thank you, Tomas Radej
FAS: tradej
11 years
Fw: Re: Letter to Legal
by Tomas Radej
Hello,
I would like to ask for your consent with me making a particular license-checking program as a thesis assignment. This program would be about to be deployed in production, mostly in Fedora package reviewing, or for the use of individual developers outside Fedora. The problem is that the information obtained by usage of the program or disclosing obtained data could be harmful towards Fedora. Please read on for details.
The assignment is to invent a tool that:
- searches a software project (for the purpose of the thesis, only a Java software project, but more language-specific modules are intended in the future)
- determines the project's license (the means of doing that, beyond checking the license header, are to be invented)
- reports any problems or license incompatibilities found (mostly as warnings, I expect most of the checks to be based on heuristics)
- stores data in a publicly available database to speed up the process and share information, taking into consideration different builds of packages, different versions etc.
The assignment also requires devising a way to manage the database, user contributions, credibility of such etc.
It is to be noted that even though checking the compliance with Fedora licensing is a duty of every reviewer, my experience shows that it is beyond a standard package reviewer to see problems such as copy/pasted code, several classes taken from a different project with a different license (when a header is missing) etc. The aim of this program would be to help mainly with these problems as they often go unnoticed even now.
The problem is that for a successful defense of the thesis, it would be necessary (admittedly not vital) to publish the source code of the program and probably the database properties as well. I am aware that disclosing the data accumulated while checking projects in Fedora could have potentially devastating consequences, therefore I would only publish the source code of the program and bindings to a database system, which a user would need to run separately from Fedora, thus not revealing the internal data to the public. My thesis advisor deemed this idea to be satisfactory for the academia.
What I would like to ask you is if you too consider the execution of this project to be safe enough to be done and not threaten Fedora, e. g. by pointing out unnoticed licensing issues to a malefactor.
Thank you, Tomas Radej
FAS: tradej
11 years
*GPL ... approaching 1990s?
by Matej Cepl
Hi,
I was contemplating to use LGPL for a small project of mine (in the end
I've decided otherwise for other reasons) but I was again struck by the
sheer nonsense of attaching 481 lines long COPYING.LGPL to 194 lines
long script. Would there be anything wrong with replacing the standard
LGPL copyright blurb with this acknowledging an existence of the Internet?
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later
version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Lesser General Public License for more details.
A copy of the full GNU Lesser General Public License is
available at http://www.gnu.org/licenses/old-licenses\
/lgpl-2.1.html (or some better URL).
Best,
Matěj
--
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
undefined
11 years
Comments on draft trademark guidelines regarding non-software merchandise produced by the Fedora Project
by inode0
Hi Pam and everyone,
I'd like to give some feedback and will try my hardest to not be
negative about it.
Here is the section I'm considering and how it might affect our current work.
http://fedoraproject.org/wiki/User:Pchestek/TMGuidelinesDraft#Non-softwar...
One general observation is that not all non-software promotional
merchandise is designed or arranged by ambassadors. Most of the time
this work is done by ambassadors, but not always. So, if possible, I'd
like to describe these sections a bit more generally to not exclude
people who do make contributions this way who are not in the
ambassador group when they do it.
Maybe something like "Fedora Event Promotional Merchandise" rather
than "Ambassador giveaways" and having more emphasis throughout on
"contributors" rather than on "ambassadors" although we do want to be
clear that we are talking about merchandise designed and made by
members of the Fedora Project primarily or exclusively for the purpose
of distribution at Fedora events.
I think a trac instance to enter some basic information about what is
produced is fine, actually a good thing generally. Will it be visible
to the public? Can it include some additional fields that we might
desire for our own tracking and expense recording as long as it
includes the fields you need as well? I do have a few comments about
the listed fields.
Contact info for responsible ambassador <- Fine aside from preferring
contributor to ambassador.
Main event(s) where materials will be given away <- This one could be
problematic so I'd like to understand what you really need at a
minimum for this field. We have, for example, produced 20,000
temporary tattoos in a single run and distributed those worldwide.
>From there they found their way (and still do) to Fedora events all
over the world over a number of years. So this list would be long and
would need updated a lot and really the original reporter (responsible
ambassador/contributor) probably isn't in a position to follow up on
where the item was used. We very seldom produce merchandise for a
specific event. Almost always it is produced in large quantities,
distributed to various geographic regions, and then finds its way on
to the events where it is needed.
Design of non-software promotional item(s) <- What does this mean? A
copy of the artwork? A proof from the vendor? A general description?
Information on vendor producing materials <- This one is easy if a URL
or basic contact info is enough.
Description of materials being used (e.g. type of tshirt, type of
coffee cup, etc) <- I'm not really sure what you want here. Just a
description of the product being made?
Amount of materials to be produced at this time in this design for
this event or events <- This is fine but the "for this event or
events" concerns me because as I said before we don't usually have a
specific list of events in mind that we are producing merchandise for
beyond any Fedora event that comes up where the item is appropriate
until we run out of it.
"If the design is simply an unmodified Fedora logo, word-mark, or
previously approved design, with nothing else, the merchandise is
appropriate, and the material type/quality is acceptable, the request
will be granted, and the Fedora Ambassador will be given a one-time
permission to produce the specified non-software promotional goods in
the amount requested."
Ok, this sounds like for this subset of cases the approval is
automatic? Or do we need something in writing from someone telling us
we can proceed? While I don't much like having to ask twice to reorder
more of an item that is popular when we run out of it, I can see some
benefit to tracking each order but would prefer to not need to wait
for permission if possible and if some fields don't really apply to
reorders noting them would ease the paperwork burden some.
"Any other request must have Board approval, and may require that the
Ambassador produce a two item proof batch of the proposed non-software
promotional goods. Please note that designs must be in compliance with
the Fedora Logo Usage Guidelines, and all requests must be made at
least one month before expected production of the non-software
promotional goods."
This part worries me some. Does it mean that each and every new item
that the project wants to produce has a bigger burden, possibly a lot
bigger burden? My radar tells me this will result in far fewer new
items getting produced which I think is undesirable. The delay this
introduces into the process is really unhelpful. I'm not sure all our
vendors would even give us binding price quotes that would allow us to
approve funding before sending the request to the Board for approval
of the trademark use. Worse, volunteers doing this will lose their
enthusiasm by this process becoming a multi-month long ordeal just to
make a new t-shirt.
I'm not clear on whether the one month delay applies to items that
will be automatically approved. If it does I really would like to
shorten that for items in that case as no one is going to want to work
on ordering some pens if that work needs to be stretched out that
long.
I do hope that most of things we produce now would fall into the
earlier category since we very often use the unmodified Fedora logo or
word-mark on items. Would it be possible to look over common Fedora
merchandise (buttons, pens, stickers, t-shirts, etc.) and tell us
which would fall into the former case and which would fall into this
latter case requiring Board approval and time delays? I'm guessing
things like t-shirts would fall into the latter more than most other
items.
And I really hope you find something in the above helpful.
Thanks,
John
11 years, 1 month
Re: [Fedora-legal-list] libzrtpcpp build faild: missing openssl/ec.h
by alekcejk＠googlemail.com
Hi,
I sent mail to libzrtpcpp developer, he answered that
disabling elliptic curve stuff is not a good idea (libzrtpcpp built now without EC).
> Other distributins seem to have no problem with it because openSSL does
> not use any of the patented enhancements for elliptic curve computations.
> I know, some time ago there were discussions about this. However, Certicom
> lost the law suits regarding their ECC patents. For more infor please
> refer to
>
> http://en.wikipedia.org/wiki/ECC_patents
So, if openSSL does not use patented ECC algorithms then maybe it
can be re-enabled in openssl package?
> On 12/26/2011 05:56 PM, alekcejk(a)googlemail.com wrote:
> > Hi,
> >
> > I tried to build libzrtpcpp-2.0.0 (see http://ftp.gnu.org/gnu/ccrtp/ ).
> > But it is impossible to build it in Fedora because
> > openssl/ec.h is disabled in openssl which is build with no-ec option.
> >
> > libzrtpcpp/crypto/openssl/ZrtpDH.cpp:46:24: fatal error: openssl/ec.h: No such file or directory
> >
> > Is it possible to build openssl with enabled openssl/ec.h?
> > If this is impossible is there any workaround for building libzrtpcpp-2.0.0?
>
> Not at this time. I am researching this issue, and hopefully we will be
> able to enable ec in the future.
>
> ~tom
>
> ==
> Fedora Project
--
Alexey Kurov <nucleo(a)fedoraproject.org>
11 years, 1 month
