Re: Re: FRR package in Debian violates the GPL licence
Paul Jama wrote:
> On Wed, 20 Mar 2019, Ole Streicher wrote:
>> My example
>>
>> #include
>> int main(void) { zlog_rotate(); return 0; }
>>
>> is not an adaption of any GPL code. It is fully written by my
>> own.
>
> It is written by you, and you have copyright in it (in some way, I
> have the vague idea there can be complex legal details in that).
>
> However, assuming this "zlog_rotate" function is non-trivial and a
> copyrightable work, then the holder of the copyright in "zlog_rotate"
> /also/ has copyright in your work. For your work is based upon the
> "zlog_rotate" work - it /is/ an adaptation of it.
>
> I know there are many programmers who can't get their head around
> that, however I don't believe that's at all contraversial amongst
> lawyers.
Of course it is controversial, that was the whole point of the
Oracle vs Google trial. It was generally believed that API is not
copyrightable, for example, BSD had the same interfaces as UNIX,
but was not a derivative of UNIX; or Wine reimplements the Windows
APIs but is not a derivative of Windows.
Oracle challenged this in 2010, claiming that Google's reimplementation
of parts of Java is a derivative work of their Java API. The court unfortunately
agreed with this, despite all previous precedents, and despite this
causing severe issues for the field (as it prevents you from re-implementing
a proprietrary API not supported anymore by the vendor, for example, or
support for proprietrary file formats).
I'm not sure why you are supporting Oracle's position, but consider
the impact on the computing world of that position, and what trouble
it causes if it wins.
There is still some hope: The case is not closed - a second supreme
court petition was filed in January.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Re: [Pkg-meego-maintainers] Packaging the MeeGo stack on Debian - Use the name ?
On Mi, 2011-01-12 at 09:26 -0600, Steve Langasek wrote: This is not a position we should back down from as a project without some very specific legal counsel about the risks and a *consensual* decision *as a project* to change our handling of trademark claims. Maintainers going it alone to ask upstreams for trademark permission, as in this case, erode Debian's overall position on trademarks vs. package and file names. Please don't do this. Far from playing it safe legally, you're instead putting at risk the work of all those other maintainers who have put countless hours into integrating around the standard upstream names. That's basically a superset of what I wrote on IRC after the initial email happened (basically, I wrote something like: asking upstream for permission is stupid, it's their trademark, and as long as nobody wants to sue you, everything is fine). I don't know why OdyX decided to do this, there was no prior discussion of this, and I never supported this, and I am sure most of the others did not support this either. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294938800.22024.22.camel@jak-thinkpad
Re: [Pkg-meego-maintainers] Packaging the MeeGo stack on Debian - Use the name ?
On Fr, 2010-12-10 at 11:24 +, MJ Ray wrote:
Ibrahim Haddad wrote:
We would ask you to move away from using {M,m}-e-e-{G,g}-o or any subset of
those letters or sounds in that order, alone or in combination with other
letters, words or marks that would tend to cause someone to make a
reasonable connection of the reference with the MeeGo mark. We specifically
discussed one possibility for illustration purposes – which is to use MG in
the place of MeeGo. We do not think that a plain text MG, when used in
reference to the code, as in a file or project or team name, would cause a
reasonable person to be confused.
OK, so for this to be possible, {M,m}-e-e-{G,g}-o must be never used
in the works of The Meego Project as a functional term. That is to
ask, is it possible to change the name without impacting on other
software which uses the works of The Meego Project? There is no
libmeego* or anything like that?
If there is a libmeego*, then clearly meego should be used in some way
for interoperability and I suggest the trademark policy changes to be
reasonable and explicitly allow use of meego as part of functional
names. That is, drop the file name constraint above. It's just
honest description of the upstream source of the code and not
necessarily used in product names. File names aren't normally covered
by trademarks, are they?
If there isn't a libmeego* or similar, I guess all is well and I
thank everyone for clarifying it.
There is libmeegotouch and a lot of stuff has meego in the package
names, we can't really change that without breaking compatibility.
Some further things for Ibrahim:
* Our team name is a unix group name and it's pkg-meego (meaning
package software from MeeGo). The trademark is used to refer to
the upstream part, so people know what is packaged. That's the
same for pkg-mozilla and all the other teams, and just a
technical detail. We'd like to keep it, since changing it is
impossible (you need to delete the old group and create a new
one instead).
* I propose that we use MeeGo in other things like this:
* Replace:
* Debian MeeGo Team
* Debian MeeGo stack maintainers
* Debian MeeGo packaging Team
* By:
* Packagers of MeeGo-originated and related
software
* This makes it clear that MeeGo refers to upstream only,
and that this is not officially MeeGo.
* Package names contain meego everywhere. According to common
believe, they are not subject to trademark restrictions (that's
why we had a firefox compatibility package for
firefox-iceweasel transition). They are merely an
implementation detail, that MeeGo set in stone, and we cannot
change it without breaking compatibility
So, I propose that we replace occurences of MeeGo in descriptive text
with MeeGo-originated, and use meego only (and only as a technical
detail such as file or package name) where we are required to do so,
that is, in libraries like libmeegotouch. From my reading this is
consistent with the trademark policy and it clearly shows that it is not
meego.
Furthermore, if MeeGo is an open project and the MeeGo trademark owned
by LF, why is Nokia handled differently than anyone else? Why are they
allowed to use MeeGo/Harmattan for the next product when it is in fact
not MeeGo?
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
--
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1291984699.6095.19.ca...@jak-thinkpad
Bug#492623: ttf-liberation: Trademark prevents modifications
Package: ttf-liberation Version: 1.04~beta2-2 Severity: important Quoting the license: The LIBERATION trademark is a trademark of Red Hat, Inc. in the U.S. and other countries. This agreement does not permit Client to distribute modified versions of the Software using Red Hat's trademarks. If Client makes a redistribution of a modified version of the Software, then Client must modify the files names to remove any reference to the Red Hat trademarks and must not use the Red Hat trademarks in any way to reference or promote the modified Software. If you modify the files, you must - Rename the fonts to remove any reference to Liberation - Not install the fonts as liberation - Rename the binary package and the source package - Change the description to remove all references to Liberation and Red Hat. This makes updates almost impossible. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ttf-liberation depends on: ii defoma 0.11.10-0.2 Debian Font Manager -- automatic f ttf-liberation recommends no packages. ttf-liberation suggests no packages. -- no debconf information signature.asc Description: Digital signature
