Licensing directions for Fedora content
by Karsten Wade
http://iquaid.org/2009/01/06/the-outside-and-inside-of-documentation-or-w...
I fully understand Thilo's points, and in many ways he is correct.
Would there be value in pursuing additional licensing for Fedora
Documentation?
To be clear -- we really want to trust our lawyers on this one, so in
the end, what they recommend or require is surely the way to go. But
we can go a long way toward influencing their opinion on the community
value of a licensing decision, outside of the legal value.
In a nutshell, here is why we have not used the CC or GNU FDL in
Fedora Docs:
* CC has no warranty protection clause. This is important in
countries such as the US; we put out technical content that could
blow up someone's computer if they misuse it or we edit it
incorrectly, we don't want to be liable for that.
But perhaps we can use a CC and add a "NO WARRANTY" clause? Or, add
the "NO WARRANTY" clause to the document itself so it is modifiable
by anyone willing to take on the increased risk?
* The GNU Free Documentation License 1.0 (FDL) is notoriously
difficult to use, unless you use it with strict guidelines on how
not to trip yourself up; this is essentially Debian's approach AIUI.
Thilo's example of not being able to pull in GNOME documentation
because of not being able to mix FDL in to OPL content is true.
However, when we did use the FDL and pursued blending in GNOME
content, we faced the various FDL requirements. They are not hard
to maintain, just ... tedious. I was happier linking out the GNOME
Documentation Guidelines rather than pulling them directly in to our
own guide; less to maintain.
I hear the new FDL is addressing these downfalls (issues with using
invariant sections, cover texts, enormous license and attribution
notices, etc.)
The OPL is not an abandoned license AFAIK. Even if it is no longer
maintained, it is not requiring maintenance. It is linked from the
front of the active http://opencontent.org. (The opencontent.org/wiki
is under a CC license, fwiw ...)
Regardless of all that, if Red Hat wants to continue using the OPL,
perhaps Fedora Docs could dual-license content. That way we could
blend in GNU FDL content from e.g. GNOME, and do it so it doesn't
actually mix with our dual-licensed content for our OPL-preferring
downstream.
I've been involved with Docs licensing for a long time, and I'm
willing to let my opinion evolve. I think that Thilo is making good
points mixed with some inaccuracies and an overly strong tone.
Perhaps it is time to reconsider Fedora content licensing from the
stand point of the community itself.
- Karsten
--
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
15 years
Tomorrow's Meeting Agenda
by Eric Christensen
Does anyone have anything specific to add to tomorrow's agenda? I want
to get that nailed down tonight if possible.
Thanks,
Eric
15 years
Re: Licensing directions for Fedora content
by Richard Fontana
Hi,
I have been following the thread on Fedora content licensing and, since
Red Hat Legal was mentioned, I wanted to make a few comments, speaking
here as a licensing lawyer for Red Hat.
The Docs Project licensing FAQ
http://fedoraproject.org/wiki/DocsProject/Licensing/FAQ
says:
The legal counsel for the Fedora Project carefully examined all of
the well-known content licenses, and concluded that only the OPL
met all of the criteria for an unambiguous and enforceable license
that would guarantee the freedoms of contributors and users.
This was Red Hat's best judgment at the time, but it no longer
represents Red Hat's view. All free (not to mention non-free and
quasi-free) content licenses that we know of have flaws, and the
OPL isn't the worst, but, while I don't want to unduly disparage the
OPL, I cannot see how anyone can, today, justifiably regard it as the
best. The use of the OPL certainly has been an important part of Red
Hat's history, and Fedora's history, but it is perhaps best regarded as
a legacy content license, favored by Red Hat during a transitional
period in which Red Hat's documentation licensing policy was gradually
liberalized.
In a posting in this thread, Spot said that Red Hat Legal "tolerates"
Fedora's use of the OPL. That's accurate; part of that tolerance is an
appreciation (which has grown over time) for the difficulties involved
in license changes and the community expectations that have been built
up around longstanding license policies.
Red Hat similarly accepts what I understand to be a general preference
for the OPL by the authors on our outstanding engineering content
services team, as implemented for example in the Publican Red Hat
branding package. Within limits, Red Hat gives its developers and
content authors significant discretion to select licenses for software
and documentation. The practice of adding nonfree restrictions (for
which the OPL uses the Orwellian term "options"), which once
characterized much Red Hat documentation and distinguished it from
Fedora's, is however no longer acceptable. All Red Hat-copyrighted
OPL-licensed documentation is now therefore available under vanilla OPL,
and thus any reference to "options" can be ignored.
The Docs Project licensing FAQ says:
The documentation provided by Red Hat, Inc. is licensed under the
OPL today, and has been using the optional clauses to prevent the
documents being modified and published without permission.
Red Hat is going to remove those optional clauses and use the same
license as Fedora Documentation. More details about this are
forthcoming.
The removal of the "options" is now accomplished as a matter of policy.
(Anyone who sees any post-2008 Red Hat documentation licensed under
OPL+"options" is encouraged to file a bug report.)
The statement seems to suggest that Red Hat has a single-license policy
for documentation, but that has (as far as I can tell) never been so,
any more than we have had, say, a GPLv2-only policy for software. Red
Hat has, and continues to, license some of its copyrighted documentation
under the GFDL, for example, and indeed under ordinary FOSS licenses.
The FAQ says:
Red Hat documentation that uses the same OPL licensing is going to
be able to intermingle content with the Fedora community.
I don't know how much of a real desire there is for such
intermingling, but in general this intermingling has always been
possible for Red Hat-copyrighted documentation. For example, I
mentioned that Red Hat licenses some of its copyrighted documentation
under the GFDL. Suppose Fedora switches content licensing to CC-BY-SA.
Even though GFDL and CC-BY-SA are basically incompatible, Red Hat can
generally permit the Fedora community to use GFDL-licensed Red
Hat-copyrighted documentation under CC-BY-SA if requested to do so.
The issue about Creative Commons and absence of warranty disclaimers
must reflect either a mistaken reading by us or (less likely, I think) a
misunderstanding of something we said. As far as I can tell, all
Creative Commons licenses have had boilerplate warranty disclaimers
from the get-go.
- Richard
--
Richard E. Fontana
Open Source Licensing and Patent Counsel
Red Hat, Inc.
15 years
Role changes... helping new members.
by Eric Christensen
If you haven't noticed, a lot of my "leadership" comes from the Navy.
From that I am trying to extrapolate on the "Sea Dad" program where new
sailors coming to a command will have a senior member to look to for
advice, answers to questions, and to get up to speed on what they are
supposed to work on.
I need strong, active members to step up and be these senior members to
mentor the more junior members that are joining us. In this way we can
get new members up to speed and moving towards being productive members.
Our FAS system has groups and members in the system which allows us to
"manage" our members. That group includes three different types of
members: administrators, sponsors, and users. A few minutes ago I
cleaned out all the sponsors (moved them back to user status) and have
upgraded a couple of users to sponsor level.
My plan is to have these sponsors actually become a "Sea Dad" for new
members. They accept these new members by sponsoring their membership.
I'll be working with these sponsors to make sure we have consistency
with all new members.
This idea is being fleshed out more and will be discussed more in the
near future.
Eric
15 years
More Publican Pain
by John J. McDonough
Today I made the mistake of looking at the Publican produced release notes
with Internet Explorer. I can't believe it has taken me so long to make
this check, but it wasn't pleasant. They are pretty badly munged up. I
wonder if there are things we can do/set in Publican to straighten this out.
The first problem is that the first page stops with the logo image. This
eliminates the table of contents and first section. By changing the
chunking in Publican we can get the first section back, but I don't know how
to get the table of contents. And the little box where the logo belongs
looks trashy. I suspect I could modify the branding to use the png version.
I also did a different document with Publican, and all looked fine when I
looked at it on my local box, but when I moved it to a webserver off my LAN
(I believe it is RHEL), a bunch of XML shows up where the logo belongs when
viewed with FF. And it has the same issues with IE.
Second, every section number is followed by an A circumflex. I suspect this
is some sort of codepage issue, but I can't say I'm sure of that.
I checked the Fedora 10 release notes, which weren't produced with Publican,
and they are fine.
I know, why aren't I using Firerox/KonquerorOpera pick your favorite poison.
Fact is, Ryan put together the F11 RN's months ago, and amongst many
experiments, I've probably viewed them a hundred times, with Firefox, Opera,
SeaMonkey, Konqueror, Epiphany; I can't believe it has taken me this long to
look at them with IE. In spite of the inroads Firefox in particular has
made, Internet Explorer is still the big bear in the woods, and it doesn't
look good for Fedora if our documentation looks trashy.
--McD
15 years
Re: install guide draft
by A. Mani
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, Apr 3, 2009 at 9:30 PM, <fedora-docs-list-request(a)redhat.com> wrote:
Ruediger Landmann <r.landmann(a)redhat.com> wrote:
>
> Mani A wrote:
>> I had a look at some parts of
>>
>> http://rlandmann.fedorapeople.org/Installation Guide/en-US/html
>>
> Many thanks! We need eyes on this.
>> "7.22.4. SMP Motherboards and GRUB
>> In previous versions of Fedora there were two different kernel
>> versions, a uniprocessor version and an SMP version. In Fedora 11 the
>> kernel is SMP-enabled by default and will take advantage of multiple
>> core, hyperthreading, and multiple CPU capabilities when they are
>> present. This same kernel can run on single CPUs with a single core
>> and no hyperthreading. "
>>
>>
>> This is being repeated since FC-4-6?
>>
> Did the native kernel have multiprocessor support before F9?
> http://docs.fedoraproject.org/release-notes/f9/en_US/sn-Kernel.html
> (whatever version it was, the text should be clarified to name it
> specifically)
http://docs.fedoraproject.org/release-notes/fc6/en_US/sn-Kernel.html#id28...
mentions it
http://docs.fedoraproject.org/release-notes/fc5/release-notes-ISO/#id3131236
says 'There is no separate SMP kernel available for the x86_64
architecture in Fedora Core 5'
> This note will become less and less relevant with each release – at what
> point should we drop it though?
I think it is time. Very few distros have been having different
kernels for SMP and uniprocessors for 2+ years.
>> "Swap should equal 2x physical RAM for up to 2 GB of physical RAM, and
>> then an additional 1x physical RAM for any amount above 2 GB, but
>> never less than 32 MB.
>> So, if:
>> M = Amount of RAM in GB, and S = Amount of swap in GB, then
>>
>> If M < 2
>> S = M *2
>> Else
>> S = M + 2"
>>
>> Using this formula, a system with 2 GB of physical RAM would have 4 GB
>> of swap, while one with 3 GB of physical RAM would have 5 GB of swap.
>> Creating a large swap space partition can be especially helpful if you
>> plan to upgrade your RAM at a later time.
>> For systems with really large amounts of RAM (more than 32 GB) you can
>> likely get away with a smaller swap partition (around 1x, or less, of
>> physical RAM)."
>>
>>
>> The formula is not correct. Or is this the result of some special study?
>>
> The formula is the current recommendation in Red Hat Enterprise Linux
> (see http://kbase.redhat.com/faq/docs/DOC-15252 ) and is what anaconda
> will create by default when installing Red Hat Enterprise Linux or
> Fedora. I don't think we should change this recommendation unless
> anaconda's behaviour changes as well.
>
> I think the text makes it pretty clear that this recommendation is only
> indicative; it's prefaced "If you are unsure about what size swap
> partition to create..."
>
> Do you think we need to draw more attention to this being a "rule of thumb"?
Some references should be provided.
On systems with SSDs swap partitions are not recommended.
__________________________
Kernel Options
Most if not all desktop, netbook and laptop users will need the option
iommu=noaperture
It should be documented.
btw some parts of the draft guide have explicit instructions for RHEL
Best
A. Mani
- --
A. Mani
Member, Cal. Math. Soc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknWoBYACgkQunMISzvdfU6pUACfQFTm4nhYVEQm4LOMHO1JD3mb
2rIAnjsn3CLs7jlxh7XGOA06VUbUQW8s
=Rsf/
-----END PGP SIGNATURE-----
15 years
Re: install guide draft
by A. Mani
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joshua Wulf <jwulf(a)redhat.com> wrote:
> Reading its preceding text and looking at the formula, I think it should
> have been:
>
> If M < 2
> S = M *2
> Else
> S = (M - 2) + 4
>
> if there are less than 2GB in the machine then you should double it = M * 2
> if there are more than two gigs then you need the 4GB for the first two
> gigs, then 1GB for each 1GB above 2GB
>
> Which part are you calling out as wrong? The formula as regards its
> preceding text, or the whole thing?
I was saying the formula for M >= 2 is way off target.
The cited kb article 15252 confirms it.
I suggested an estimate in my OP, I think it makes sense to revise it to
If Desktop User then Min(3, 2*M)
If 4 < M < 150, then S = Max (5, M/5)
If 150 < M < 256, then S= 24
as some kind of default on the principle that
"'Default values' should be a little more than the minimum
recommended" (in this scenario).
Best
A. Mani
--
A. Mani
Member, Cal. Math. Soc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknWskUACgkQunMISzvdfU4knwCfTwQY/n7ahLIjF75syJRfQp6s
QHAAoLztvNaTyr0INgtR88O58WhDDlf1
=e7UG
-----END PGP SIGNATURE-----
15 years
Fedora 11 Release Notes
by John J. McDonough
I wanted to take a moment to thank all the folks who contributed to getting
the release notes out. They went to the translators last night, and I see
they are already hard at work.
There were an awful lot of changes this release and I know it wasn't easy.
With the switch to Publican, and the broken mw-render we had some additional
challenges, but with everyone's help we got it done.
Once again, thank you all.
--McD
15 years
Introduction
by dheeraj bansal
Hi All,
I am a Software Engineer working with a MNC since last two years and now
sincerely looking forward to contribute to open-source communities since I
believe this is the way with which we can make technology more useful,
purposeful and profitable to the humanity. I just want to continue the
fellowship and contribute my part toward my moral responsibiltiy which is to
make the world a better place.
Thanks and Regards,
Dheeraj Bansal
+929827637248
15 years
install guide draft
by A. Mani
I had a look at some parts of
http://rlandmann.fedorapeople.org/Installation Guide/en-US/html
"7.22.4. SMP Motherboards and GRUB
In previous versions of Fedora there were two different kernel
versions, a uniprocessor version and an SMP version. In Fedora 11 the
kernel is SMP-enabled by default and will take advantage of multiple
core, hyperthreading, and multiple CPU capabilities when they are
present. This same kernel can run on single CPUs with a single core
and no hyperthreading. "
This is being repeated since FC-4-6?
"Swap should equal 2x physical RAM for up to 2 GB of physical RAM, and
then an additional 1x physical RAM for any amount above 2 GB, but
never less than 32 MB.
So, if:
M = Amount of RAM in GB, and S = Amount of swap in GB, then
If M < 2
S = M *2
Else
S = M + 2"
Using this formula, a system with 2 GB of physical RAM would have 4 GB
of swap, while one with 3 GB of physical RAM would have 5 GB of swap.
Creating a large swap space partition can be especially helpful if you
plan to upgrade your RAM at a later time.
For systems with really large amounts of RAM (more than 32 GB) you can
likely get away with a smaller swap partition (around 1x, or less, of
physical RAM)."
The formula is not correct. Or is this the result of some special study?
I think, S= min{3, 2*M} is best for most desktop users
For most servers it should be around Max(5, M/5).
Sys admins should determine the actual requirement for servers and
scientific computing.
There are some recommendations here: http://www.linux.com/feature/121916
Best
A. Mani
--
A. Mani
Member, Cal. Math. Soc
15 years