[opensuse-factory] muffin
"muffin was declined in 101506, without there is no chance" https://build.opensuse.org/request/diff/102030 What is this supposed to mean? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hallo Leute, Am Samstag, 4. Februar 2012 schrieb Nelson Marques:
"muffin was declined in 101506, without there is no chance"
https://build.opensuse.org/request/diff/102030
What is this supposed to mean?
That you should check why SR 101506 was declined ;-) https://build.opensuse.org/request/show/101506 Hint: muffin.spec does not contain a note about the spec file's license, see the last SR comment by factory-auto for details. After fixing this, submit muffin again. After it has been accepted, you can submit cinnamon (which requires muffin). Regards, Christian Boltz -- Vor einer ganzen Weile war ich zu einem Kurs über Linux. An den PC's gab es zu meinem Entsetzen keine Maus - nix mit herumklicken in KDE oder so - nur tippen in der shell. Damals habe ich mich geärgert aber heute finde ich das war das beste was mir passieren konnte. Nur wer das Alphabet kennt kann ein Buch lesen. [Torsten Seeboth in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
A license regarding the spec file? It's the first time I see this one comming... Can it be CC-NC-SA 3.0 ? As I consider a spec file a work of art :) NM 2012/2/4 Christian Boltz <opensuse@cboltz.de>:
Hallo Leute,
Am Samstag, 4. Februar 2012 schrieb Nelson Marques:
"muffin was declined in 101506, without there is no chance"
https://build.opensuse.org/request/diff/102030
What is this supposed to mean?
That you should check why SR 101506 was declined ;-) https://build.opensuse.org/request/show/101506
Hint: muffin.spec does not contain a note about the spec file's license, see the last SR comment by factory-auto for details.
After fixing this, submit muffin again. After it has been accepted, you can submit cinnamon (which requires muffin).
Regards,
Christian Boltz -- Vor einer ganzen Weile war ich zu einem Kurs über Linux. An den PC's gab es zu meinem Entsetzen keine Maus - nix mit herumklicken in KDE oder so - nur tippen in der shell. Damals habe ich mich geärgert aber heute finde ich das war das beste was mir passieren konnte. Nur wer das Alphabet kennt kann ein Buch lesen. [Torsten Seeboth in suse-linux]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Nelson Marques /* http://www.marques.so nmo.marques@gmail.com */ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Samstag, 4. Februar 2012 schrieb Nelson Marques:
A license regarding the spec file? It's the first time I see this one comming...
It's not really new - the only difference is that in the past a "default" license header [1] was added silently(!) when you submitted to Factory. (Which I didn't really like because it claimed a copyright for SUSE - even if nobody @suse.com ever touched the specfile.) Now things seem to have changed and you can - and have to - define the spec license yourself.
Can it be CC-NC-SA 3.0 ? As I consider a spec file a work of art :)
The usual way is to use the same license as the package has (except for non-OSS packages), but I don't see a real problem with using a CC license. However, the NC part might be a problem because it makes the license not-so-free. (SUSE could see problems if they decide to include your package in SLES/SLED, which is probably considered "commercial".) CC-SA should be OK - if not, the factory legal review will tell you ;-) Final note: IANAL ;-) If you want a better answer, please ask on the opensuse-bar@opensuse.org mailinglist. That's the list for discussing legal issues, and no, I have no idea who invented that name. Regards, Christian Boltz [1] something like this: # # spec file for package postfixadmin # # Copyright (c) 2012 SUSE LINUX Products GmbH, Nuernberg, Germany. # # All modifications and additions to the file contributed by third parties # remain the property of their copyright owners, unless otherwise agreed # upon. The license for this file, and modifications and additions to the # file, is the same license as for the pristine package itself (unless the # license for the pristine package is not an Open Source License, in which # case the license is the MIT License). An "Open Source License" is a # license that conforms to the Open Source Definition (Version 1.9) # published by the Open Source Initiative. # Please submit bugfixes or comments via http://bugs.opensuse.org/ # --
[...] if the installation of a stupid package failed, [...] AFAIK there is no package named `stupid'. [> Raphael Schillings and Michael Gross in https://bugzilla.novell.com/show_bug.cgi?id=147588]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04.02.2012 21:00, Christian Boltz wrote:
A license regarding the spec file? It's the first time I see this one
comming... It's not really new - the only difference is that in the past a "default" license header [1] was added silently(!) when you submitted to Factory. (Which I didn't really like because it claimed a copyright for SUSE - even if nobody @suse.com ever touched the specfile.)
Now things seem to have changed and you can - and have to - define the spec license yourself.
Really? I ever thought that the spec file, as *part* of the package, has to be under the same license then the package. Wouldn't that make more sense? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Christian, True, I'm aware of that header... Though I just believe that a general CLA (Contributors License Agreement) would be a better way out for openSUSE contributions and kill the overhead of having to write headers. That way packages wouldn't be declined because of this, which would: * improve the submission process; * save time to reviewers and contributors; * easy to account for contributions; * provide differentiation between contributors and members (instead of the dumb solution being presented by the board segregating members, which I totally disagree, while making members a voting class and contributors a more free class would be better, unless I'm trying to artificially manipulate statistics). * ease of usage; * etc etc I've added a small text establishing that the spec has the same licenses as the pristine source (which can make it also a not so free license for some cases). About the CC, the NC was intended exactly for the reason you mention, so my packages wouldn't be integrated in a commercial linux from which I earn nothing and some of them could introduce added value. Either way I haven't chose this road and complied with the previous old fashioned way, which sounds good to me. NM 2012/2/4 Christian Boltz <opensuse@cboltz.de>:
Hello,
Am Samstag, 4. Februar 2012 schrieb Nelson Marques:
A license regarding the spec file? It's the first time I see this one comming...
It's not really new - the only difference is that in the past a "default" license header [1] was added silently(!) when you submitted to Factory. (Which I didn't really like because it claimed a copyright for SUSE - even if nobody @suse.com ever touched the specfile.)
Now things seem to have changed and you can - and have to - define the spec license yourself.
Can it be CC-NC-SA 3.0 ? As I consider a spec file a work of art :)
The usual way is to use the same license as the package has (except for non-OSS packages), but I don't see a real problem with using a CC license.
However, the NC part might be a problem because it makes the license not-so-free. (SUSE could see problems if they decide to include your package in SLES/SLED, which is probably considered "commercial".)
CC-SA should be OK - if not, the factory legal review will tell you ;-)
Final note: IANAL ;-)
If you want a better answer, please ask on the opensuse-bar@opensuse.org mailinglist. That's the list for discussing legal issues, and no, I have no idea who invented that name.
Regards,
Christian Boltz
[1] something like this:
# # spec file for package postfixadmin # # Copyright (c) 2012 SUSE LINUX Products GmbH, Nuernberg, Germany. # # All modifications and additions to the file contributed by third parties # remain the property of their copyright owners, unless otherwise agreed # upon. The license for this file, and modifications and additions to the # file, is the same license as for the pristine package itself (unless the # license for the pristine package is not an Open Source License, in which # case the license is the MIT License). An "Open Source License" is a # license that conforms to the Open Source Definition (Version 1.9) # published by the Open Source Initiative.
# Please submit bugfixes or comments via http://bugs.opensuse.org/ #
--
[...] if the installation of a stupid package failed, [...] AFAIK there is no package named `stupid'. [> Raphael Schillings and Michael Gross in https://bugzilla.novell.com/show_bug.cgi?id=147588]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Nelson Marques /* http://www.marques.so nmo.marques@gmail.com */ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 5 Feb 2012 16:56:37 +0000 Nelson Marques <nmo.marques@gmail.com> wrote:
Hi Christian,
True, I'm aware of that header... Though I just believe that a general CLA (Contributors License Agreement) would be a better way out for openSUSE contributions and kill the overhead of having to write headers. That way packages wouldn't be declined because of this, which would:
* improve the submission process; * save time to reviewers and contributors; * easy to account for contributions; * provide differentiation between contributors and members (instead of the dumb solution being presented by the board segregating members, which I totally disagree, while making members a voting class and contributors a more free class would be better, unless I'm trying to artificially manipulate statistics). * ease of usage; * etc etc
I've added a small text establishing that the spec has the same licenses as the pristine source (which can make it also a not so free license for some cases). About the CC, the NC was intended exactly for the reason you mention, so my packages wouldn't be integrated in a commercial linux from which I earn nothing and some of them could introduce added value. Either way I haven't chose this road and complied with the previous old fashioned way, which sounds good to me.
NM
OK, so you want NC, so if we want to include package in SLE it just mean, that we cannot use your spec. but how can we recognize that packager doesn't look at your spec? Also question is what is your added value except collection data and write it to metadata which RPM build understand. Package name, version, license, description is usually taken from package homepage so not your data. Patches usually ( depending on license of package ) are under same license as package and they are not part of spec. So only remaining part is scripts inside spec and files section. Scripts are usually trivial text modification which is hard to recognize who do it first or if it is copied or reinvented ( of course there is some exceptions ). So remains files. Do you think that your files section is so important that you cannot use it? Another question is who benefit from it? If package is included in commercial linux it means, that there is dedicated person who spend part of their work-time to improve such package, so package benefit from ( upstream and also our spec file and also opensuse, because opensuse is base for commercial linux, so we fix also factory package ). So if you make your spec NC there is chance that commercial linux doesn't use it or maintainer need to spend part of their time to create new one instead of improving package. And last think that comes to my mind ( I am not layer or license expert ) what means that build metadata is under NC? That we should not build it for money? But in commercial linux you don't pay for packages, but for support. So it doesn't make much sense for me. Josef -- Josef Reidinger Software Engineer Appliance Department SUSE LINUX, s. r. o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic jreidinger@suse.com SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le 07/02/2012 10:46, Josef Reidinger a écrit :
On Sun, 5 Feb 2012 16:56:37 +0000 Nelson Marques<nmo.marques@gmail.com> wrote:
OK, so you want NC,
NC is not free in open source sense, so can't be included in the OSS tree and forgive the hole package to be included as well jdd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
According to your own perspective or according to OSI ? 2012/2/7 jdd <jdd@dodin.org>:
Le 07/02/2012 10:46, Josef Reidinger a écrit :
On Sun, 5 Feb 2012 16:56:37 +0000 Nelson Marques<nmo.marques@gmail.com> wrote:
OK, so you want NC,
NC is not free in open source sense, so can't be included in the OSS tree and forgive the hole package to be included as well
jdd
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Nelson Marques /* http://www.marques.so nmo.marques@gmail.com */ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le 07/02/2012 10:58, Nelson Marques a écrit :
According to your own perspective or according to OSI ?
http://www.opensource.org/faq#commercial jdd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 02/07/2012 11:05 AM, jdd wrote:
Le 07/02/2012 10:58, Nelson Marques a écrit :
According to your own perspective or according to OSI ?
http://www.opensource.org/faq#commercial Recently we figured out (the given distro did not contact us), that a Linux distro was throwing out syslog-ng because man pages were using a "NC" license. This is now fixed ( http://git.balabit.hu/?p=bazsi/syslog-ng-3.3.git;a=commit;h=a299854e07b26ddf... ), and the ParabolaGnuLinux guys are now happy :-) Summary: NC is not free enough.
Bye, CzP Ps: this and other syslog-ng licensing related topics in my FOSDEM presentation: http://czanik.blogs.balabit.com/2012/02/fosdem-syslog-ng-as-upstream/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Sorry, I don't do religion :) 2012/2/7 Peter Czanik <pczanik@fang.fa.gau.hu>:
On 02/07/2012 11:05 AM, jdd wrote:
Le 07/02/2012 10:58, Nelson Marques a écrit :
According to your own perspective or according to OSI ?
Recently we figured out (the given distro did not contact us), that a Linux distro was throwing out syslog-ng because man pages were using a "NC" license. This is now fixed ( http://git.balabit.hu/?p=bazsi/syslog-ng-3.3.git;a=commit;h=a299854e07b26ddf... ), and the ParabolaGnuLinux guys are now happy :-) Summary: NC is not free enough.
Bye, CzP
Ps: this and other syslog-ng licensing related topics in my FOSDEM presentation: http://czanik.blogs.balabit.com/2012/02/fosdem-syslog-ng-as-upstream/
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Nelson Marques /* http://www.marques.so nmo.marques@gmail.com */ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le 07/02/2012 11:40, Nelson Marques a écrit :
Sorry, I don't do religion :)
:-) yes, I know, I'm also sometime disturbed by this licence thing, but I had to study this in details and recognise that limiting licenses gives more trubble than benefits, specially when many small parts are involved, having several licence types in the same package is a nightmare :-) jdd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Do you want to maintain them? I can easilly find something else to do. 2012/2/7 Josef Reidinger <jreidinger@suse.cz>:
On Sun, 5 Feb 2012 16:56:37 +0000 Nelson Marques <nmo.marques@gmail.com> wrote:
Hi Christian,
True, I'm aware of that header... Though I just believe that a general CLA (Contributors License Agreement) would be a better way out for openSUSE contributions and kill the overhead of having to write headers. That way packages wouldn't be declined because of this, which would:
* improve the submission process; * save time to reviewers and contributors; * easy to account for contributions; * provide differentiation between contributors and members (instead of the dumb solution being presented by the board segregating members, which I totally disagree, while making members a voting class and contributors a more free class would be better, unless I'm trying to artificially manipulate statistics). * ease of usage; * etc etc
I've added a small text establishing that the spec has the same licenses as the pristine source (which can make it also a not so free license for some cases). About the CC, the NC was intended exactly for the reason you mention, so my packages wouldn't be integrated in a commercial linux from which I earn nothing and some of them could introduce added value. Either way I haven't chose this road and complied with the previous old fashioned way, which sounds good to me.
NM
OK, so you want NC, so if we want to include package in SLE it just mean, that we cannot use your spec. but how can we recognize that packager doesn't look at your spec? Also question is what is your added value except collection data and write it to metadata which RPM build understand. Package name, version, license, description is usually taken from package homepage so not your data. Patches usually ( depending on license of package ) are under same license as package and they are not part of spec. So only remaining part is scripts inside spec and files section. Scripts are usually trivial text modification which is hard to recognize who do it first or if it is copied or reinvented ( of course there is some exceptions ). So remains files. Do you think that your files section is so important that you cannot use it?
Another question is who benefit from it? If package is included in commercial linux it means, that there is dedicated person who spend part of their work-time to improve such package, so package benefit from ( upstream and also our spec file and also opensuse, because opensuse is base for commercial linux, so we fix also factory package ). So if you make your spec NC there is chance that commercial linux doesn't use it or maintainer need to spend part of their time to create new one instead of improving package.
And last think that comes to my mind ( I am not layer or license expert ) what means that build metadata is under NC? That we should not build it for money? But in commercial linux you don't pay for packages, but for support. So it doesn't make much sense for me.
Josef
-- Josef Reidinger Software Engineer Appliance Department
SUSE LINUX, s. r. o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic
jreidinger@suse.com SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Nelson Marques /* http://www.marques.so nmo.marques@gmail.com */ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 7 Feb 2012 10:06:38 +0000 Nelson Marques <nmo.marques@gmail.com> wrote:
Do you want to maintain them? I can easilly find something else to do.
Hi, I don't decrease your credit. I just don't see any benefit from restricting usage. Of course people have different reason why contribute to open-source and it is up to you what license you choose. Just I want to point out, that for improving open source software is not good way to restrict usage of your work. From my POV is good to force anyone to share his improvements to software ( GPL ) so you can also benefit from it, but I don't see much benefit from restricting usage ( but you are free to choose anything ). Josef
2012/2/7 Josef Reidinger <jreidinger@suse.cz>:
On Sun, 5 Feb 2012 16:56:37 +0000 Nelson Marques <nmo.marques@gmail.com> wrote:
Hi Christian,
True, I'm aware of that header... Though I just believe that a general CLA (Contributors License Agreement) would be a better way out for openSUSE contributions and kill the overhead of having to write headers. That way packages wouldn't be declined because of this, which would:
* improve the submission process; * save time to reviewers and contributors; * easy to account for contributions; * provide differentiation between contributors and members (instead of the dumb solution being presented by the board segregating members, which I totally disagree, while making members a voting class and contributors a more free class would be better, unless I'm trying to artificially manipulate statistics). * ease of usage; * etc etc
I've added a small text establishing that the spec has the same licenses as the pristine source (which can make it also a not so free license for some cases). About the CC, the NC was intended exactly for the reason you mention, so my packages wouldn't be integrated in a commercial linux from which I earn nothing and some of them could introduce added value. Either way I haven't chose this road and complied with the previous old fashioned way, which sounds good to me.
NM
OK, so you want NC, so if we want to include package in SLE it just mean, that we cannot use your spec. but how can we recognize that packager doesn't look at your spec? Also question is what is your added value except collection data and write it to metadata which RPM build understand. Package name, version, license, description is usually taken from package homepage so not your data. Patches usually ( depending on license of package ) are under same license as package and they are not part of spec. So only remaining part is scripts inside spec and files section. Scripts are usually trivial text modification which is hard to recognize who do it first or if it is copied or reinvented ( of course there is some exceptions ). So remains files. Do you think that your files section is so important that you cannot use it?
Another question is who benefit from it? If package is included in commercial linux it means, that there is dedicated person who spend part of their work-time to improve such package, so package benefit from ( upstream and also our spec file and also opensuse, because opensuse is base for commercial linux, so we fix also factory package ). So if you make your spec NC there is chance that commercial linux doesn't use it or maintainer need to spend part of their time to create new one instead of improving package.
And last think that comes to my mind ( I am not layer or license expert ) what means that build metadata is under NC? That we should not build it for money? But in commercial linux you don't pay for packages, but for support. So it doesn't make much sense for me.
Josef
-- Josef Reidinger Software Engineer Appliance Department
SUSE LINUX, s. r. o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic
jreidinger@suse.com SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Josef Reidinger Software Engineer Appliance Department SUSE LINUX, s. r. o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic jreidinger@suse.com SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Josef, Previously to your reply I had already introduced the text from the old SUSE copyright headers regarding the license of the spec file, assigning it to the pristine source license as long as it's compliant with OSI otherwise to become MIT. The thing is, I don't do religion like many people around, because religion is -evil-. If I want to condition my packages for non-commercial usage I should be able to do it as we don't have a contributors license agreement, just a plain code of conduct for social/civil purposes. Furthermore, about SUSE people... Many time ago there was 'quvi' which was required upgrades to fix a few dependencies (totem-pl-parser)... I've updated it and fixed the bug and became maintainer of the package. Later that package was hijacked, commits were made rebellious to me will... So please, I have all the reasons for not wanting my packages to be enabled in SLE, because they can be victimized by the same arrogance of some commiters who haven't learned to respect others work. Best of luck, NM 2012/2/7 Josef Reidinger <jreidinger@suse.cz>:
On Tue, 7 Feb 2012 10:06:38 +0000 Nelson Marques <nmo.marques@gmail.com> wrote:
Do you want to maintain them? I can easilly find something else to do.
Hi, I don't decrease your credit. I just don't see any benefit from restricting usage. Of course people have different reason why contribute to open-source and it is up to you what license you choose. Just I want to point out, that for improving open source software is not good way to restrict usage of your work. From my POV is good to force anyone to share his improvements to software ( GPL ) so you can also benefit from it, but I don't see much benefit from restricting usage ( but you are free to choose anything ).
Josef
2012/2/7 Josef Reidinger <jreidinger@suse.cz>:
On Sun, 5 Feb 2012 16:56:37 +0000 Nelson Marques <nmo.marques@gmail.com> wrote:
Hi Christian,
True, I'm aware of that header... Though I just believe that a general CLA (Contributors License Agreement) would be a better way out for openSUSE contributions and kill the overhead of having to write headers. That way packages wouldn't be declined because of this, which would:
* improve the submission process; * save time to reviewers and contributors; * easy to account for contributions; * provide differentiation between contributors and members (instead of the dumb solution being presented by the board segregating members, which I totally disagree, while making members a voting class and contributors a more free class would be better, unless I'm trying to artificially manipulate statistics). * ease of usage; * etc etc
I've added a small text establishing that the spec has the same licenses as the pristine source (which can make it also a not so free license for some cases). About the CC, the NC was intended exactly for the reason you mention, so my packages wouldn't be integrated in a commercial linux from which I earn nothing and some of them could introduce added value. Either way I haven't chose this road and complied with the previous old fashioned way, which sounds good to me.
NM
OK, so you want NC, so if we want to include package in SLE it just mean, that we cannot use your spec. but how can we recognize that packager doesn't look at your spec? Also question is what is your added value except collection data and write it to metadata which RPM build understand. Package name, version, license, description is usually taken from package homepage so not your data. Patches usually ( depending on license of package ) are under same license as package and they are not part of spec. So only remaining part is scripts inside spec and files section. Scripts are usually trivial text modification which is hard to recognize who do it first or if it is copied or reinvented ( of course there is some exceptions ). So remains files. Do you think that your files section is so important that you cannot use it?
Another question is who benefit from it? If package is included in commercial linux it means, that there is dedicated person who spend part of their work-time to improve such package, so package benefit from ( upstream and also our spec file and also opensuse, because opensuse is base for commercial linux, so we fix also factory package ). So if you make your spec NC there is chance that commercial linux doesn't use it or maintainer need to spend part of their time to create new one instead of improving package.
And last think that comes to my mind ( I am not layer or license expert ) what means that build metadata is under NC? That we should not build it for money? But in commercial linux you don't pay for packages, but for support. So it doesn't make much sense for me.
Josef
-- Josef Reidinger Software Engineer Appliance Department
SUSE LINUX, s. r. o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic
jreidinger@suse.com SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Josef Reidinger Software Engineer Appliance Department
SUSE LINUX, s. r. o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic
jreidinger@suse.com SUSE
-- Nelson Marques /* http://www.marques.so nmo.marques@gmail.com */ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 7 Feb 2012 11:14:00 +0000 Nelson Marques <nmo.marques@gmail.com> wrote:
I've updated it and fixed the bug and became maintainer of the package. Later that package was hijacked, commits were made rebellious to me will...
Do we speak about FOSS software, where is possible to take sources, branch them, make changes and let users choose which one they will use? If there will be more details, it would be possible to see why "rebellious" upsets you, otherwise it can be just result of your somewhat sensitive nature and tendency to jump to conclusions without giving yourself time to digest facts. (That is visible from many posts, where technical stuff is mixed with emotional outbursts.) In any case such events should be discussed on project mail list, as if they exist they are not beneficial to project. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (7)
-
Christian Boltz -
jdd -
Josef Reidinger -
Kim Leyendecker -
Nelson Marques -
Peter Czanik -
Rajko M.